TESTING.md - external/github.com/docker/cli - Git at Google

 # Testing

 The following guidelines summarize the testing policy for docker/cli.

 ## Unit Test Suite

 All code changes should have unit test coverage.

 Error cases should be tested with unit tests.

 Bug fixes should be covered by new unit tests or additional assertions in
 existing unit tests.

 ### Details

 The unit test suite follows the standard Go testing convention. Tests are
 located in the package directory in `_test.go` files.

 Unit tests should be named using the convention:

 ```
 Test<Function Name><Test Case Name>
 ```

 [Table tests](https://github.com/golang/go/wiki/TableDrivenTests) should be used
 where appropriate, but may not be appropriate in all cases.

 Assertions should be made using
 [gotest.tools/assert](https://godoc.org/gotest.tools/assert).

 Fakes, and testing utilities can be found in
 [internal/test](https://godoc.org/github.com/docker/cli/internal/test) and
 [gotest.tools](https://godoc.org/gotest.tools).

 ## End-to-End Test Suite

 The end-to-end test suite tests a cli binary against a real API backend.

 ### Guidelines

 Each feature (subcommand) should have a single end-to-end test for
 the success case. The test should include all (or most) flags/options supported
 by that feature.

 In some rare cases a couple additional end-to-end tests may be written for a
 sufficiently complex and critical feature (ex: `container run`, `service
 create`, `service update`, and `docker build` may have ~3-5 cases each).

 In some rare cases a sufficiently critical error paths may have a single
 end-to-end test case.

 In all other cases the behaviour should be covered by unit tests.

 If a code change adds a new flag, that flag should be added to the existing
 "success case" end-to-end test.

 If a code change fixes a bug, that bug fix should be covered either by adding
 assertions to the existing end-to-end test, or with one or more unit test.

 ### Details

 The end-to-end test suite is located in
 [./e2e](https://github.com/docker/cli/tree/master/e2e). Each directory in `e2e`
 corresponds to a directory in `cli/command` and contains the tests for that
 subcommand. Files in each directory should be named `<command>_test.go` where
 command is the basename of the command (ex: the test for `docker stack deploy`
 is found in `e2e/stack/deploy_test.go`).

 Tests should be named using the convention:

 ```
 Test<Command Basename>[<Test Case Name>]
 ```

 where the test case name is only required when there are multiple test cases for
 a single command.

 End-to-end test should run the `docker` binary using
 [gotestyourself/icmd](https://godoc.org/github.com/gotestyourself/gotestyourself/icmd)
 and make assertions about the exit code, stdout, stderr, and local file system.

 Any Docker image or registry operations should use `registry:5000/<image name>`
 to communicate with the local instance of the registry. To load
 additional fixture images to the registry see
 [scripts/test/e2e/run](https://github.com/docker/cli/blob/master/scripts/test/e2e/run).
	# Testing

	The following guidelines summarize the testing policy for docker/cli.

	## Unit Test Suite

	All code changes should have unit test coverage.

	Error cases should be tested with unit tests.

	Bug fixes should be covered by new unit tests or additional assertions in
	existing unit tests.

	### Details

	The unit test suite follows the standard Go testing convention. Tests are
	located in the package directory in `_test.go` files.

	Unit tests should be named using the convention:

	```
	Test<Function Name><Test Case Name>
	```

	[Table tests](https://github.com/golang/go/wiki/TableDrivenTests) should be used
	where appropriate, but may not be appropriate in all cases.

	Assertions should be made using
	[gotest.tools/assert](https://godoc.org/gotest.tools/assert).

	Fakes, and testing utilities can be found in
	[internal/test](https://godoc.org/github.com/docker/cli/internal/test) and
	[gotest.tools](https://godoc.org/gotest.tools).

	## End-to-End Test Suite

	The end-to-end test suite tests a cli binary against a real API backend.

	### Guidelines

	Each feature (subcommand) should have a single end-to-end test for
	the success case. The test should include all (or most) flags/options supported
	by that feature.

	In some rare cases a couple additional end-to-end tests may be written for a
	sufficiently complex and critical feature (ex: `container run`, `service
	create`, `service update`, and `docker build` may have ~3-5 cases each).

	In some rare cases a sufficiently critical error paths may have a single
	end-to-end test case.

	In all other cases the behaviour should be covered by unit tests.

	If a code change adds a new flag, that flag should be added to the existing
	"success case" end-to-end test.

	If a code change fixes a bug, that bug fix should be covered either by adding
	assertions to the existing end-to-end test, or with one or more unit test.

	### Details

	The end-to-end test suite is located in
	[./e2e](https://github.com/docker/cli/tree/master/e2e). Each directory in `e2e`
	corresponds to a directory in `cli/command` and contains the tests for that
	subcommand. Files in each directory should be named `<command>_test.go` where
	command is the basename of the command (ex: the test for `docker stack deploy`
	is found in `e2e/stack/deploy_test.go`).

	Tests should be named using the convention:

	```
	Test<Command Basename>[<Test Case Name>]
	```

	where the test case name is only required when there are multiple test cases for
	a single command.

	End-to-end test should run the `docker` binary using
	[gotestyourself/icmd](https://godoc.org/github.com/gotestyourself/gotestyourself/icmd)
	and make assertions about the exit code, stdout, stderr, and local file system.

	Any Docker image or registry operations should use `registry:5000/<image name>`
	to communicate with the local instance of the registry. To load
	additional fixture images to the registry see
	[scripts/test/e2e/run](https://github.com/docker/cli/blob/master/scripts/test/e2e/run).