runc/tests/integration
Adrian Reber ec260653b7 lazy-migration: add test case
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>
2017-09-06 12:35:39 +00:00
..
testdata adds integration tests 2016-04-21 19:09:27 -05:00
README.md Updating README for starting the container 2016-06-05 14:41:58 +05:30
cgroups.bats tests: don't call wait_for_container after synchronous operations 2017-05-02 21:48:07 +03:00
checkpoint.bats lazy-migration: add test case 2017-09-06 12:35:39 +00:00
create.bats tests: fix all the things 2016-12-01 15:49:37 +11:00
debug.bats Rename start to run 2016-05-31 11:06:41 -07:00
delete.bats Ignore error when force deleting a non-existing container 2017-05-16 22:23:00 +02:00
events.bats tests: don't call wait_for_container after synchronous operations 2017-05-02 21:48:07 +03:00
exec.bats tests: don't call wait_for_container after synchronous operations 2017-05-02 21:48:07 +03:00
help.bats tests: add rootless integration tests 2017-03-23 20:46:22 +11:00
helpers.bash Fix integration when missing criu 2017-07-14 20:15:20 +08:00
kill.bats tests: don't call wait_for_container after synchronous operations 2017-05-02 21:48:07 +03:00
list.bats tests: don't call wait_for_container after synchronous operations 2017-05-02 21:48:07 +03:00
mask.bats tests: don't call wait_for_container after synchronous operations 2017-05-02 21:48:07 +03:00
pause.bats tests: don't call wait_for_container after synchronous operations 2017-05-02 21:48:07 +03:00
ps.bats tests: don't call wait_for_container after synchronous operations 2017-05-02 21:48:07 +03:00
root.bats tests: don't call wait_for_container after synchronous operations 2017-05-02 21:48:07 +03:00
spec.bats vendor: clean up to be better written 2017-04-25 10:46:48 +10:00
start.bats Only allow single container operation 2017-03-08 10:02:39 +08:00
start_detached.bats tests: don't call wait_for_container after synchronous operations 2017-05-02 21:48:07 +03:00
start_hello.bats tests: add rootless integration tests 2017-03-23 20:46:22 +11:00
state.bats tests: don't call wait_for_container after synchronous operations 2017-05-02 21:48:07 +03:00
tty.bats tests: don't call wait_for_container after synchronous operations 2017-05-02 21:48:07 +03:00
update.bats Update spec to 239c4e44f2 2017-06-01 16:29:47 -07:00
version.bats bats: refactor run "$RUNC" -> runc 2016-05-26 19:17:39 +10:00

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"* ]]
}