1dee43319c
This turned out to be messier than I thought, because of two primary factors; the biggest mess here of course is the indirection through the DBus API. The other problem is that previously we passed the string to render each time, and with current indicatif that'd trigger a rerender. Since (usually) don't change the "prefix string", rework the API. Change the "percent/n_items" bits to use autocleanups as well, and to take the prefix string as an initial argument. Since the state expands to multiple components, also change the API to use the `0-initialized` pattern rather than trying to return an aggregate. We also gain a "sub message" which we use to display e.g. package names as we're doing checkouts. Note this ends up at the end, since otherwise everything else jumps around. Closes: #1661 Approved by: rfairley |
||
---|---|---|
.. | ||
check | ||
common | ||
compose-tests | ||
composedata | ||
ex-container-tests | ||
gpghome | ||
manual | ||
utils | ||
vmcheck | ||
compose | ||
ex-container | ||
README.md |
Tests are divided into three groups:
-
Tests in the
check
directory are non-destructive and uninstalled. Some of the tests require root privileges. Usemake check
to run these. -
The
composecheck
tests currently require uid 0 capabilities - the default in Docker, or you can run them via a user namespace. They are non-destructive, but are installed.To use them, you might do a
make && sudo make install
inside a Docker container.Then invoke
./tests/compose
. Alternatively of course, you can simply run the tests on a host system or in an existing container, without doing a build.Note: This is intentionally not a
Makefile
target because it doesn't require building and doesn't use uninstalled binaries. -
Tests in the
vmcheck
directory are oriented around using Vagrant. Usemake vmcheck
to run them. See alsoHACKING.md
in the top directory.
The common
directory contains files used by multiple
tests. The utils
directory contains helper utilities
required to run the tests.