ec260653b7
The lazy-pages test case is not as straight forward as the other test cases. This is related to the fact that restoring requires a different name if restored on the same host. During 'runc checkpoint' the container is not destroyed before all memory pages have been transferred to the destination and thus the same container name cannot be used. As real world usage will rather migrate a container from one system to another than lazy migrate a container on the same host this is only problematic for this test case. Another reason is that it requires starting 'runc checkpoint' and 'criu lazy-pages' in the background as those process need to be running to start the final restore 'runc restore'. CRIU upstream is currently discussing to automatically start 'criu lazy-pages' which would simplify the lazy-pages test case a bit. The handling and checking of the background processes make the test case not the most elegant as at one point a 'sleep 2' is required to make sure that 'runc checkpoint' had time to do its thing before looking at log files. Before running the actual test criu is called in feature checking mode to make sure lazy migration is in the test case criu enabled. If not, the test is skipped. Signed-off-by: Adrian Reber <areber@redhat.com> |
||
---|---|---|
.. | ||
testdata | ||
README.md | ||
cgroups.bats | ||
checkpoint.bats | ||
create.bats | ||
debug.bats | ||
delete.bats | ||
events.bats | ||
exec.bats | ||
help.bats | ||
helpers.bash | ||
kill.bats | ||
list.bats | ||
mask.bats | ||
pause.bats | ||
ps.bats | ||
root.bats | ||
spec.bats | ||
start.bats | ||
start_detached.bats | ||
start_hello.bats | ||
state.bats | ||
tty.bats | ||
update.bats | ||
version.bats |
README.md
runc Integration Tests
Integration tests provide end-to-end testing of runc.
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:
$ make integration
Alternatively, you can run integration tests directly on your host through make:
$ sudo make localintegration
Or you can just run them directly using bats
$ sudo bats tests/integration
To run a single test bucket:
$ make integration TESTFLAGS="/checkpoint.bats"
To run them on your host, you will need to setup a development environment plus bats For example:
$ cd ~/go/src/github.com
$ git clone https://github.com/sstephenson/bats.git
$ cd bats
$ ./install.sh /usr/local
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/opencontainers/runc/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
# setup is called at the beginning of every test.
function setup() {
# see functions teardown_hello and setup_hello in helpers.bash, used to
# create a pristine environment for running your tests
teardown_hello
setup_hello
}
# teardown is called at the end of every test.
function teardown() {
teardown_hello
}
@test "this is a simple test" {
runc run containerid
# "The runc macro" automatically populates $status, $output and $lines.
# Please refer to bats documentation to find out more.
[ "$status" -eq 0 ]
# check expected output
[[ "${output}" == *"Hello"* ]]
}