spiegel_podman/test
Ed Santiago a9dbd2b3de Migrate away from docker.io
CI and system tests currently pull some images from docker.io.
Eliminate that, by:

  - building a custom image containing much of what we need
    for testing; and
  - copying other needed images to quay.io

(Reason: effective 2020-11-01 docker.io will limit the
number of image pulls).

The principal change is to create a new quay.io/libpod/testimage,
using the new test/system/build-testimage script, instead of
relying on quay.io/libpod/alpine_labels. We also switch to
using a hardcoded :YYYYMMDD tag, instead of :latest, in an
attempt to futureproof our CI. This image includes 'httpd'
from busybox-extras, which we use in our networking test
(previously we had to pull and run busybox from docker.io).

The testimage can and should be extended as needed for future
tests, e.g. adding test file content or other useful tools.

For the '--pull' tests which require actually pulling from
the registry, I've created an image with the same name but
tagged :00000000 so it will never be pulled by default.
Since this image is only used minimally, it's just busybox.

Unfortunately there remain two cases we cannot solve in
this tiny alpine-based image:

  1) docker registry
  2) systemd

For those, I've (manually) run:

    podman pull [ docker.io/library/registry:2.7 | registry.fedoraproject.org/fedora:31 ]
    podman tag !$ quay.io/...
    podman push !$

...and amended the calling tests accordingly.

I've tried to make the the smallest reasonable diff, not the
smallest possible one. I hope it's a reasonable tradeoff.

Signed-off-by: Ed Santiago <santiago@redhat.com>
2020-09-08 06:06:06 -06:00
..
apiv2 APIv2 test: add more tests for containers 2020-09-01 04:00:39 -04:00
build Vendor in latest github.com/projectatomic/buildah 2018-08-03 14:39:07 +00:00
certs Add new key and never-expiring test certificate 2019-03-20 13:36:17 -04:00
checkseccomp Don't pollute the build output with failures to build checkseccomp 2018-07-26 20:47:31 +00:00
e2e Fix unconfined AppArmor profile usage for unsupported systems 2020-09-07 10:47:32 +02:00
endpoint Remove some unnecessary []byte to string conversions 2020-08-03 09:13:04 +02:00
framework Update registrar unit tests to match them of cri-o 2019-04-04 08:53:32 +02:00
goecho Separate common used test functions and structs to test/utils 2018-11-16 10:49:00 +08:00
install Enable pre-commit tool linting 2020-01-14 13:42:59 +00:00
python/dockerpy Fix python dockerpy tests 2020-06-24 12:40:55 -07:00
system Migrate away from docker.io 2020-09-08 06:06:06 -06:00
utils Merge pull request #7216 from 5eraph/master 2020-08-09 07:45:20 -04:00
policy.json Initial checkin from CRI-O repo 2017-11-01 11:24:59 -04:00
README.md Update cni config instructions 2019-08-22 19:39:07 -04:00
redhat_sigstore.yaml Initial checkin from CRI-O repo 2017-11-01 11:24:59 -04:00
registries.conf Cirrus: Overhaul/Simplify env. var setup 2019-05-21 08:44:02 -04:00
test_podman_baseline.sh Use bash binary from env instead of /bin/bash for scripts 2020-08-17 10:42:23 +02:00
test_podman_build.sh Use bash binary from env instead of /bin/bash for scripts 2020-08-17 10:42:23 +02:00
test_podman_pods.sh Use bash binary from env instead of /bin/bash for scripts 2020-08-17 10:42:23 +02:00
trust_set_test.json Enable pre-commit tool linting 2020-01-14 13:42:59 +00:00

PODMAN logo

Test utils

Test utils provide common functions and structs for testing. It includes two structs:

  • PodmanTest: Handle the podman command and other global resources like temporary directory. It provides basic methods, like checking podman image and pod status. Test suites should create their owner test struct as a composite of PodmanTest, and their owner PodmanMakeOptions().

  • PodmanSession: Store execution session data and related methods. Such like get command output and so on. It can be used directly in the test suite, only embed it to your owner session struct if you need expend it.

Unittest for test/utils

To ensure neither tests nor utils break, There are unit-tests for each functions and structs in test/utils. When you adding functions or structs to this package, please update both unit-tests for it and this documentation.

Run unit test for test/utils

Run unit test for test/utils.

make localunit

Structure of the test utils and test suites

The test utils package is at the same level of test suites. Each test suites also have their owner common functions and structs stored in libpod_suite_test.go.

Ginkgo test framework

Ginkgo is a BDD testing framework. This allows us to use native Golang to perform our tests and there is a strong affiliation between Ginkgo and the Go test framework.

Installing dependencies

The dependencies for integration really consists of three things:

  • ginkgo binary

The following instructions assume your GOPATH is ~/go. Adjust as needed for your environment.

Installing ginkgo

Build ginkgo and install it under $GOPATH/bin with the following commands:

export GOCACHE="$(mktemp -d)"
GOPATH=~/go make .install.ginkgo

If your PATH does not include $GOPATH/bin, you might consider adding it.

PATH=$PATH:$GOPATH/bin

Integration Tests

Test suite for integration test for podman command line. It has its own structs:

  • PodmanTestIntegration: Integration test struct as a composite of PodmanTest. It set up the global options for podman command to ignore the environment influence from different test system.

  • PodmanSessionIntegration: This struct has it own methods for checking command output with given format JSON by using structs defined in inspect package.

Running the integration tests

You can run the entire suite of integration tests with the following command:

GOPATH=~/go ginkgo -v test/e2e/.

Note the trailing period on the command above. Also, -v invokes verbose mode. That switch is optional.

Running a single file of integration tests

You can run a single file of integration tests using the go test command:

GOPATH=~/go go test -v test/e2e/libpod_suite_test.go test/e2e/common_test.go test/e2e/config.go test/e2e/config_amd64.go test/e2e/your_test.go

Running a single integration test

Before running the test suite, you have to declare which test you want run in the test file itself. Consider the following actual test:

It("podman inspect bogus pod", func() {
		session := podmanTest.Podman([]string{"pod", "inspect", "foobar"})
		session.WaitWithDefaultTimeout()
		Expect(session.ExitCode()).To(Not(Equal(0)))
	})

To mark this as the test you want run, you simply change the It description to FIt. Please note how both the F and I are capitalized.

You can run a single integration test using the same command we used to run all the tests in a single file.

GOPATH=~/go go test -v test/e2e/libpod_suite_test.go test/e2e/common_test.go test/e2e/config.go test/e2e/config_amd64.go test/e2e/your_test.go

Note: Be sure you remove the F from the tests before committing your changes or you will skip all tests in that file except the one with the FIt denotation.

Run tests in a container

In case you have issue running the tests locally on your machine, you can run them in a container:

make shell

This will run a container and give you a shell and you can follow the instructions above.

System tests

System tests are used for testing the podman CLI in the context of a complete system. It requires that podman, all dependencies, and configurations are in place. The intention of system testing is to match as closely as possible with real-world user/developer use-cases and environments. The orchestration of the environments and tests is left to external tooling.

System tests use Bash Automated Testing System (bats) as a testing framework. Install it via your package manager or get latest stable version directly from the repository, e.g.:

mkdir -p ~/tools/bats
git clone --single-branch --branch v1.1.0 https://github.com/bats-core/bats-core.git ~/tools/bats

Make sure that bats binary (bin/bats in the repository) is in your PATH, if not - add it:

PATH=$PATH:~/tools/bats/bin

Running system tests

When bats is installed and is in your PATH, you can run the test suite with following command:

make localsystem

Contributing to system tests

Please see the TODO list of needed workflows/tests.