Kir Kolyshkin
d5e68ceb0c
Commita9e15e7e0adds a check that stdin/out/err pipes are restored correctly. Commitec260653b7copy/pastes the same code to one more another test. Problem is (as pointed out in commit5369f9ade3) these tests sometimes hang. I have also seen them fail. Apparently, the code used to create pipes and open them to fds is racy: ```shell cat $fifo | cat $fifo & pid=$! exec 50</proc/$pid/fd/0 exec 51>/proc/$pid/fd/0 ``` Since `cat | cat` is spawned asynchronously, by the time exec is used, the second cat process (i.e. $pid) is already fork'ed but it might not be exec'ed yet. As a result, we get this (`ls -l /proc/self/fd`): ``` lr-x------. 1 root root 64 Apr 20 02:39 50 -> /dev/pts/1 l-wx------. 1 root root 64 Apr 20 02:39 51 -> /dev/pts/1 ``` or, in some cases: ``` lr-x------. 1 root root 64 Apr 20 02:45 50 -> /dev/pts/1 l-wx------. 1 root root 64 Apr 20 02:45 51 -> 'pipe:[215791]' ``` instead of expected set of pipes: ``` > lr-x------. 1 root root 64 Apr 20 02:45 50 -> 'pipe:[215791]' > l-wx------. 1 root root 64 Apr 20 02:45 51 -> 'pipe:[215791]' ``` One possible workaround is to add `sleep 0.1` or so after cat|cat, but it is outright ugly (besides, we already have one sleep in the test code). The solution is to not use any external processes to create pipes. I admit this still looks not very comprehensible, but at least it is easier than before, and it works. While at it, remove code duplication, moving the setup and check code into a pair of functions. Finally, since the tests are working now, remove the skip. Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
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 TESTPATH="/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"* ]]
}