These specs are used to specify tests you can run in apps and libs. These do not exist as distinct documents but as subfields of lib and app specs. They are found under the test key.
How Dusty Runs Tests
To facilitate quick turnaround times with testing, Dusty does the following to run tests:
- Pull or create the image defined in
- Run the
oncescript and commit the resulting image locally
- Use the image from Step 2 as the starting point for all test suite runs
image specifies a Docker image on which to base the container used to create the
intermediate testing image. If the image does not exist locally, Dusty will pull it.
image is hosted in a private registry which requires authentication,
you can add
image_requires_login: True to force the user to authenticate
before Dusty attempts to pull down the image.
image must be supplied in the test spec. They cannot both be supplied.
build specifies a directory containing a Dockerfile on the host OS which will be used
to build the intermediate testing image.
This path can be absolute or relative. If it is relative, it is relative to repo directory on the host OS.
image must be supplied in the spec. They cannot both be supplied.
once: - pip install -r test_requirements.txt
once specifies the commands used in Step 2 of test image creation to create a final
testing image. The resulting image is committed locally and used as the starting point
for test suite runs.
Expensive install steps should go in
once so that Dusty can cache their results.
suites specifies a list of test suites available for this app or lib. Each suite provides
description keys which are shown when using the
dusty test command.
Each suite may also contain the following keys:
services: - testMongo - testRedis
services provides a list of Dusty services which will be linked to the test container for this
suite. Containers are spun up for each service and linked to the final test container. All containers
for a given test suite are also connected to the same network stack. This allows your testing
container to access ports exposed by any test services through its own
Unlike runtime container dependencies, each test suite gets its own copy of the service containers. This provides service isolation across multiple apps and test suites.
command: - nosetests
command defines the script to be run to perform the test for this suite.
Tests can accept arguments at runtime through the
dusty test command. Arguments are passed through
to the final command specified by the
command list for the suite.
default_args allows you to specify arguments which are passed to the final command in the
command list if no arguments are given at runtime. If the user provides arguments to
dusty test command, the
default_args are ignored.
In this example, the following Dusty commands would cause the following commands to be run inside the suite's container:
> dusty test my-app suiteName => nosetests tests/unit > dusty test my-app suiteName tests/integration => nosetests tests/integration
compose: environment: APP_ENVIRONMENT: local MONGO_HOST: persistentMongo
Dusty uses Docker Compose to create and manage containers. The
compose key allows you to
override any of the values passed through to Docker Compose at runtime.
For more information on what you can override through this key, please see the Docker Compose specification.