f28ad7749f
GNU roff 1.23 stopped remapping unescaped Hyphen-Minus (ie., - or 0x2D) characters in the input to Hyphen-Minus in the output. Instead, it follows the specified behaviour of converting unescaped Hyphen-Minus characters in the input to Hyphen (ie., ‐ or 0x2010) in the output. To get Hyphen-Minus characters in the output, one needs to escape the Hyphen-Minus with a backslash (ie., \-) in the input [1]. Therefore, the command line options documented in the manuals are no longer prefixed with the Hyphen-Minus character that's needed to ctually use them. This breaks copying and pasting from the manuals and searching within them. Unfortunately, escaping the Hyphen-Minus characters in Markdown doesn't have the intended effect of having Hyphen-Minus in the generated manual pages [2]. Therefore, this is worked around by having the tests check for both Hyphen-Minus and Hyphen. Note that some operating system distributions, like Debian, have reverted this change from GNU roff, but others haven't. So, unless it can be guaranteed that the manuals will always have Hyphen-Minus regardless of which GNU roff version or variant is being used, the tests need to check for both. [1] https://lwn.net/Articles/947941/ https://lists.gnu.org/archive/html/info-gnu/2023-07/msg00001.html https://git.savannah.gnu.org/cgit/groff.git/tree/PROBLEMS?h=1.23.0#n82 [2] https://github.com/cpuguy83/go-md2man/issues/101 https://github.com/containers/toolbox/pull/1398 |
||
---|---|---|
.. | ||
libs | ||
001-version.bats | ||
002-help.bats | ||
101-create.bats | ||
102-list.bats | ||
103-container.bats | ||
104-run.bats | ||
105-enter.bats | ||
106-rm.bats | ||
107-rmi.bats | ||
108-completion.bats | ||
201-ipc.bats | ||
203-network.bats | ||
206-user.bats | ||
210-ulimit.bats | ||
211-dbus.bats | ||
220-environment-variables.bats | ||
meson.build | ||
README.md | ||
setup_suite.bash |
System tests
These tests are built with BATS (Bash Automated Testing System).
The tests are meant to ensure that Toolbox's functionality remains stable throughout updates of both Toolbox and Podman/libpod.
The tests are set up in a way that does not affect the host environment. Running them won't remove any existing containers or images.
Dependencies
awk
bats
GNU coreutils
httpd-tools
openssl
podman
skopeo
toolbox
These tests use a few standard libraries for bats
which help with clarity
and consistency. The libraries are bats-support
and bats-assert. These libraries are
provided as git submodules in the libs
directory. Make sure both are present
by running git submodule init
and git submodule update
.
How to run the tests
First, make sure you have all the dependencies installed.
- Enter the toolbox root folder
- Invoke command
bats ./test/system/
and the test suite should fire up
Mocking of images is done automatically to prevent potential networking issues and to speed up the cases.
By default the test suite uses the system versions of podman
, skopeo
and
toolbox
.
If you have a podman
, skopeo
or toolbox
installed in a nonstandard
location then you can use the PODMAN
, SKOPEO
and TOOLBOX
environmental
variables to set the path to the binaries. So the command to invoke the test
suite could look something like this: PODMAN=/usr/libexec/podman TOOLBOX=./toolbox bats ./test/system/
.
When running the tests, make sure the test suite: [job]
jobs are successful.
These jobs set up the whole environment and are a strict requirement for other
jobs to run correctly.
Writing tests
Environmental variables
- Inspect top part of
libs/helpers.bats
for a list of helper environmental variables
Naming convention
- All tests should follow the nomenclature:
[command]: <test description>...
- When the test is expected to fail, start the test description with "Try to..."
- When the test is to give a non obvious output, it should be put in parenthesis at the end of the title
Examples:
@test "create: Create the default container"
@test "rm: Try to remove a non-existent container"
Test case environment
- All the tests start with a clean system (no images or containers) to make sure
that there are no dependencies between tests and they are really isolated. Use
the
setup()
andteardown()
functions for that purpose.
Image registry
-
The system tests set up an OCI image registry for testing purposes -
localhost:50000
. The registry requires authentication. There is one account present:user
(password:user
) -
The registry contains by default only one image:
fedora-toolbox:34
Example pull of the fedora-toolbox:34
image:
$PODMAN login --username user --password user "$DOCKER_REG_URI"
$PODMAN pull "$DOCKER_REG_URI/fedora-toolbox:34"