docs/test/integration
Victor Vieux 068a587f17 fix issue with last docker
Signed-off-by: Victor Vieux <vieux@docker.com>
2015-09-18 03:06:14 -07:00
..
api fix pull return code 2015-09-10 04:10:28 -04:00
compose choose docker-compose version 2015-08-31 22:19:17 -07:00
discovery update discovery url 2015-09-02 21:04:04 -07:00
mesos Merge pull request #1155 from vieux/fix_mesos_logs 2015-09-03 13:10:52 +07:00
testdata choose docker-compose version 2015-08-31 22:19:17 -07:00
Dockerfile switch to golang 1.5 2015-09-01 04:18:39 -07:00
README.md Fix a pair of typos in the docs 2015-07-29 13:53:13 +01:00
affinities.bats integration: more debug into affinity 2015-05-12 14:54:36 -07:00
api_version.bats fix api_version test 2015-06-30 11:48:08 -07:00
cli.bats integration: cleanup debug echo and test names 2015-05-06 15:47:28 -07:00
constraints.bats integration: more debug into affinity 2015-05-12 14:54:36 -07:00
dependency.bats merge volumes-from integration tests 2015-05-16 08:22:17 +08:00
helpers.bash choose docker-compose version 2015-08-31 22:19:17 -07:00
port-filters.bats fix race in tests 2015-09-17 15:26:10 -07:00
replication.bats Integration test for leader election 2015-07-28 18:26:52 -07:00
resource_management.bats fix issue with last docker 2015-09-18 03:06:14 -07:00
run.sh try to use gnu version of readlink if available 2015-09-11 15:25:33 -07:00
swarm_id.bats swarm IDs: Convert Swarm ID to Container ID in API Proxy. 2015-05-11 16:56:08 -07:00
test_runner.sh choose docker-compose version 2015-08-31 22:19:17 -07:00

README.md

Swarm Integration Tests

Integration tests provide end-to-end testing of Swarm.

While unit tests verify the code is working as expected by relying on mocks and artificially created fixtures, integration tests actually use real docker engines and communicate with Swarm through the CLI.

Note that integration tests do not replace unit tests.

As a rule of thumb, code should be tested thoroughly with unit tests. Integration tests on the other hand are meant to test a specific feature end to end.

Integration tests are written in bash using the bats framework.

Running integration tests

The easiest way to run integration tests is with Docker:

$ test/integration/run.sh

Alternatively, you can run integration tests directly on your host:

$ bats test/integration

In order to do that, you will need to setup a full development environment plus bats

Note: There are known issues running the integration tests using devicemapper as a storage driver, make sure that your docker daemon is using aufs if you want to successfully run the integration tests.

Writing integration tests

[helper functions] (https://github.com/docker/swarm/blob/master/test/integration/helpers.bash) are provided in order to facilitate writing tests.

#!/usr/bin/env bats

# This will load the helpers.
load helpers

@test "this is a simple test" {
	# start_docker will start a given number of engines:
	start_docker 2

	# The address of those engines is available through $HOSTS:
	run docker -H ${HOSTS[0]} info
	# "run" automatically populates $status, $output and $lines.
	# Please refer to bats documentation to find out more.
	[ "$status" -eq 0 ]

	# You can start multiple docker engines in the same test:
	start_docker 1
	# Their address will be *appended* to $HOSTS. Therefore, since this is the 3rd
	# engine started, its index will be 2:
	run docker -H ${HOSTS[2]} info  

	# Additional parameters can be passed to the docker daemon:
	start_docker 1 --label foo=bar

	# swarm_manage will start the swarm manager, preconfigured with all engines
	# previously started by start_engine:
	swarm_manage

	# You can talk with said manager by using the docker_swarm helper:
	run docker_swarm info
	[ "$status" -eq 0 ]
	[ "${lines[1]}"="Nodes: 4" ]
}

# teardown is called at the end of every test.
function teardown() {
	# This will stop the swarm manager:
	swarm_manage_cleanup

	# This will stop and remove all engines launched by the test:
	stop_docker
}