toolbox/test/system
Debarshi Ray c3403dae8c Drop one "o" and rename the project as "Toolbx"
This is meant to make the project more searchable on the Internet.  More
and more people have been pointing out that "toolbox" is terribly
difficult to search for, and it's impossible to find any decent
Internet real estate by that name.

Some exceptions:

  * The code repository is still https://github.com/containers/toolbox.
    It will be renamed after giving a heads-up to other contributors.

  * The name of the binary is still 'toolbox'.  The name is embedded
    into existing Toolbx containers as their entry point, which is bind
    mounted from the host operating system when the containers are
    started.  Trivially renaming the binary will prevent these
    containers from starting.

  * For similar reasons, the TOOLBOX_PATH environment variable is still
    the same.

  * For similar reasons, the profile.d file to be read by the shell on
    start-up is still called toolbox.sh.

  * The label used to identify Toolbx containers and images is still
    called com.github.containers.toolbox.  There are many existing
    Toolbx containers, and many Toolbx images beyond the control of the
    Toolbx project that use this label to identity themselves.  Simply
    renaming the label will prevent these containers and images from
    being recognized.

  * The names of the built-in Toolbx images still retain the word
    'toolbox'.  Images under the new name need to be published on the
    OCI registries and the toolbox(1) binary needs to be taught to
    handle both old and new names, wherever necessary, for backwards
    compatibility.

  * The stamp file used to identify Toolbx containers is still called
    /run/.toolboxenv because it's used by various external programs and
    users to identify Toolbx containers.

  * The OSC 777 escape sequence to track and preserve the user's current
    Toolbx container [1] still emits 'toolbox' as the name of the
    container runtime.  Changing the escape sequence can break terminal
    emulation applications, like Prompt [2], that consume it.  Hence, it
    needs to be done carefully.

  * The runtime directories at /run/toolbox, when used as root, and
    $XDG_RUNTIME_DIR/toolbox, when used rootless, weren't renamed.

    When used as root, /run/toolbox is embedded into existing Toolbx
    containers as a bind mount from the host.  Trivially renaming the
    path will prevent these containers from starting.

    Secondly, both these paths are used to synchronize container
    start-up.  If the paths are trivially renamed, and the toolbox(1)
    binary is updated and used without stopping all existing containers,
    then it won't be able to enter containers that were already started.
    Strictly speaking, this scenario isn't supported, since updates are
    always expected to be "offline" [3].  However, it's worth noting
    because solving the previous problem might also address this.

  * The configuration file for RPM is still called
    /usr/lib/rpm/macros.d/macros.toolbox.

[1] https://gitlab.freedesktop.org/terminal-wg/specifications/-/issues/17

[2] https://gitlab.gnome.org/chergert/prompt

[3] https://www.freedesktop.org/software/systemd/man/latest/systemd.offline-updates.html

https://github.com/containers/toolbox/issues/1399
2024-02-06 18:24:26 +01:00
..
libs Drop one "o" and rename the project as "Toolbx" 2024-02-06 18:24:26 +01:00
001-version.bats Drop one "o" and rename the project as "Toolbx" 2024-02-06 18:24:26 +01:00
002-help.bats Drop one "o" and rename the project as "Toolbx" 2024-02-06 18:24:26 +01:00
101-create.bats Drop one "o" and rename the project as "Toolbx" 2024-02-06 18:24:26 +01:00
102-list.bats Drop one "o" and rename the project as "Toolbx" 2024-02-06 18:24:26 +01:00
103-container.bats test/system: Silence SC2155 2023-09-20 10:24:29 +02:00
104-run.bats Drop one "o" and rename the project as "Toolbx" 2024-02-06 18:24:26 +01:00
105-enter.bats Drop one "o" and rename the project as "Toolbx" 2024-02-06 18:24:26 +01:00
106-rm.bats Drop one "o" and rename the project as "Toolbx" 2024-02-06 18:24:26 +01:00
107-rmi.bats Drop one "o" and rename the project as "Toolbx" 2024-02-06 18:24:26 +01:00
108-completion.bats Drop one "o" and rename the project as "Toolbx" 2024-02-06 18:24:26 +01:00
201-ipc.bats Drop one "o" and rename the project as "Toolbx" 2024-02-06 18:24:26 +01:00
203-network.bats Drop one "o" and rename the project as "Toolbx" 2024-02-06 18:24:26 +01:00
206-user.bats Drop one "o" and rename the project as "Toolbx" 2024-02-06 18:24:26 +01:00
210-ulimit.bats Drop one "o" and rename the project as "Toolbx" 2024-02-06 18:24:26 +01:00
211-dbus.bats Drop one "o" and rename the project as "Toolbx" 2024-02-06 18:24:26 +01:00
220-environment-variables.bats Drop one "o" and rename the project as "Toolbx" 2024-02-06 18:24:26 +01:00
README.md Drop one "o" and rename the project as "Toolbx" 2024-02-06 18:24:26 +01:00
meson.build test/system: Test that environment variables for Bash history are kept 2023-09-30 14:22:31 +02:00
setup_suite.bash test/system: Replace the RHEL toolbox:8.7 image with toolbox:8.9 2024-01-24 22:45:18 +01:00

README.md

System tests

These tests are built with BATS (Bash Automated Testing System).

The tests are meant to ensure that Toolbx's functionality remains stable throughout updates of both Toolbx 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 TOOLBX 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 TOOLBX=./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() and teardown() 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"