github.com/xdlianrong208/docker-ce-comments@v17.12.1-ce-rc2+incompatible/components/cli/TESTING.md (about)

     1  # Testing
     2  
     3  The following guidelines summarize the testing policy for docker/cli.
     4  
     5  ## Unit Test Suite
     6  
     7  All code changes should have unit test coverage.
     8  
     9  Error cases should be tested with unit tests.
    10  
    11  Bug fixes should be covered by new unit tests or additional assertions in
    12  existing unit tests.
    13  
    14  ### Details
    15  
    16  The unit test suite follows the standard Go testing convention. Tests are
    17  located in the package directory in `_test.go` files.
    18  
    19  Unit tests should be named using the convention:
    20  
    21  ```
    22  Test<Function Name><Test Case Name>
    23  ```
    24  
    25  [Table tests](https://github.com/golang/go/wiki/TableDrivenTests) should be used
    26  where appropriate, but may not be appropriate in all cases.
    27  
    28  Assertions should be made using
    29  [testify/assert](https://godoc.org/github.com/stretchr/testify/assert) and test
    30  requirements should be verified using
    31  [testify/require](https://godoc.org/github.com/stretchr/testify/require).
    32  
    33  Fakes, and testing utilities can be found in
    34  [internal/test](https://godoc.org/github.com/docker/cli/internal/test) and
    35  [gotestyourself](https://godoc.org/github.com/gotestyourself/gotestyourself).
    36  
    37  ## End-to-End Test Suite
    38  
    39  The end-to-end test suite tests a cli binary against a real API backend.
    40  
    41  ### Guidelines
    42  
    43  Each feature (subcommand) should have a single end-to-end test for 
    44  the success case. The test should include all (or most) flags/options supported
    45  by that feature.
    46  
    47  In some rare cases a couple additional end-to-end tests may be written for a
    48  sufficiently complex and critical feature (ex: `container run`, `service 
    49  create`, `service update`, and `docker build` may have ~3-5 cases each).
    50  
    51  In some rare cases a sufficiently critical error paths may have a single
    52  end-to-end test case.
    53  
    54  In all other cases the behaviour should be covered by unit tests.
    55  
    56  If a code change adds a new flag, that flag should be added to the existing 
    57  "success case" end-to-end test.
    58  
    59  If a code change fixes a bug, that bug fix should be covered either by adding 
    60  assertions to the existing end-to-end test, or with one or more unit test.
    61  
    62  ### Details
    63  
    64  The end-to-end test suite is located in
    65  [./e2e](https://github.com/docker/cli/tree/master/e2e). Each directory in `e2e`
    66  corresponds to a directory in `cli/command` and contains the tests for that
    67  subcommand. Files in each directory should be named `<command>_test.go` where
    68  command is the basename of the command (ex: the test for `docker stack deploy`
    69  is found in `e2e/stack/deploy_test.go`).
    70  
    71  Tests should be named using the convention:
    72  
    73  ```
    74  Test<Command Basename>[<Test Case Name>]
    75  ```
    76  
    77  where the test case name is only required when there are multiple test cases for
    78  a single command.
    79  
    80  End-to-end test should run the `docker` binary using
    81  [gotestyourself/icmd](https://godoc.org/github.com/gotestyourself/gotestyourself/icmd)
    82  and make assertions about the exit code, stdout, stderr, and local file system.
    83  
    84  Any Docker image or registry operations should use `registry:5000/<image name>`
    85  to communicate with the local instance of the Docker registry. To load 
    86  additional fixture images to the registry see
    87  [scripts/test/e2e/run](https://github.com/docker/cli/blob/master/scripts/test/e2e/run).