cri-o/test
Nalin Dahyabhai c0333b102b Integrate containers/storage
Use containers/storage to store images, pod sandboxes, and containers.
A pod sandbox's infrastructure container has the same ID as the pod to
which it belongs, and all containers also keep track of their pod's ID.

The container configuration that we build using the data in a
CreateContainerRequest is stored in the container's ContainerDirectory
and ContainerRunDirectory.

We catch SIGTERM and SIGINT, and when we receive either, we gracefully
exit the grpc loop.  If we also think that there aren't any container
filesystems in use, we attempt to do a clean shutdown of the storage
driver.

The test harness now waits for ocid to exit before attempting to delete
the storage root directory.

Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
2017-01-18 10:23:30 -05:00
..
testdata test: Add host pod ping test 2016-12-21 12:24:37 +01:00
apparmor.bats cmd/client: move pod create to pod run 2016-12-14 18:15:37 +01:00
ctr.bats test: Do not hardcode runc specific output 2017-01-14 02:02:45 +01:00
helpers.bash Integrate containers/storage 2017-01-18 10:23:30 -05:00
network.bats Remove host ping test 2017-01-17 13:43:23 -08:00
pod.bats cmd/client: move pod create to pod run 2016-12-14 18:15:37 +01:00
policy.json Integrate containers/storage 2017-01-18 10:23:30 -05:00
README.md test: fix readme and sleep just 1 2016-09-27 10:46:50 +02:00
restore.bats cmd/client: move pod create to pod run 2016-12-14 18:15:37 +01:00
runtimeversion.bats test: add more debugging output 2016-10-02 19:13:00 +11:00
seccomp.bats cmd/client: move pod create to pod run 2016-12-14 18:15:37 +01:00
test_runner.sh add tests skeleton 2016-09-24 00:37:07 +02:00

OCID Integration Tests

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

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 test

To run a single test bucket:

$ make integration TESTFLAGS="runtimeversion.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

Writing integration tests

[Helper functions] (https://github.com/kubernetes-incubator/ocid/blob/master/test/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() {
}

# teardown is called at the end of every test.
function teardown() {
	cleanup_test
}

@test "ocic runtimeversion" {
	start_ocid
	ocic runtimeversion
	[ "$status" -eq 0 ]
}