Skip to content
This repository has been archived by the owner on Feb 7, 2024. It is now read-only.

Latest commit

 

History

History
89 lines (62 loc) · 3.3 KB

TESTING.md

File metadata and controls

89 lines (62 loc) · 3.3 KB
Raw

Testing

This document contains the Moby code testing guidelines. It should answer any questions you may have as an aspiring Moby contributor.

Test suites

Moby has two test suites (and one legacy test suite):

  • Unit tests - use standard go test and gotest.tools/assert assertions. They are located in the package they test. Unit tests should be fast and test only their own package.
  • API integration tests - use standard go test and gotest.tools/assert assertions. They are located in ./integration/<component> directories, where component is: container, image, volume, etc. These tests perform HTTP requests to an API endpoint and check the HTTP response and daemon state after the call.

The legacy test suite integration-cli/ is deprecated. No new tests will be added to this suite. Any tests in this suite which require updates should be ported to either the unit test suite or the new API integration test suite.

Writing new tests

Most code changes will fall into one of the following categories.

Writing tests for new features

New code should be covered by unit tests. If the code is difficult to test with a unit tests then that is a good sign that it should be refactored to make it easier to reuse and maintain. Consider accepting unexported interfaces instead of structs so that fakes can be provided for dependencies.

If the new feature includes a completely new API endpoint then a new API integration test should be added to cover the success case of that endpoint.

If the new feature does not include a completely new API endpoint consider adding the new API fields to the existing test for that endpoint. A new integration test should not be added for every new API field or API error case. Error cases should be handled by unit tests.

Writing tests for bug fixes

Bugs fixes should include a unit test case which exercises the bug.

A bug fix may also include new assertions in an existing integration tests for the API endpoint.

Integration tests environment considerations

When adding new tests or modifying existing test under integration/, testing environment should be properly considered. skip.If from gotest.tools/skip can be used to make the test run conditionally. Full testing environment conditions can be found at environment.go

Here is a quick example. If the test needs to interact with a docker daemon on the same host, the following condition should be checked within the test code

skip.If(t, testEnv.IsRemoteDaemon())
// your integration test code

If a remote daemon is detected, the test will be skipped.

Running tests

To run the unit test suite:

make test-unit

or hack/test/unit from inside a BINDDIR=. make shell container or properly configured environment.

The following environment variables may be used to run a subset of tests:

  • TESTDIRS - paths to directories to be tested, defaults to ./...
  • TESTFLAGS - flags passed to go test, to run tests which match a pattern use TESTFLAGS="-test.run TestNameOrPrefix"

To run the integration test suite:

make test-integration