TESTS(7)

NAME
tests - introduction to the NetBSD test suite

DESCRIPTION
The NetBSD test suite provides a collection of automated tests for two major purposes. On the one hand, the test suite aids developers in catching bugs and regressions in the code when they performing modifications to the source tree. On the other hand, the test suite allows end users (and, in particular, system administrators) to verify that fresh installations of the NetBSD operating system behave correctly in their hardware platform and also to ensure that the system does not suffer from regressions during regular system operation and maintenance.

The NetBSD test suite is distributed as a separate installation set, named tests.tgz, and the test programs are all installed under the /usr/tests hierarchy.

This manual page describes how to execute the test suite and how to configure some of its optional features.

  When to run the tests?
Before diving into the details of how to run the test suite, here are some scenarios in which you should be running them:

•   After a fresh installation of NetBSD to ensure that the system works correctly on your hardware platform.

•   After an upgrade of NetBSD to a different version to ensure that the new code works well on your hardware platform and that the upgrade did not introduce regressions in your configuration.

•   After performing changes to the source tree to catch any bugs and/or regressions introduced by the modifications.

•   Periodically, maybe from a cron(8) job, to ensure that any changes to the system (such as the installation of third-party packages or manual modifications to configuration files) do not introduce unexpected failures.

  Installing the tests
If you chose to install the tests.tgz distribution set while setting up your NetBSD system, the tests are already available in /usr/tests. Otherwise, install the set now by running:

    # cd /
    # tar xzpf /path/to/tests.tgz

  Running the tests
Use the following command to run the whole test suite:

    $ kyua test -k /usr/tests/Kyuafile

The above will go through all test programs in /usr/tests recursively, execute them, store their results and debugging data in Kyua database (by default in ~/.kyua/store.db), and print a summary of the results. This summary includes a brief count of all total tests run and how many of them failed.

It is possible to restrict which tests to run by providing their names in the command line. For example, this would execute the tests for the cp(1) and cut(1) utilities:

    $ kyua test -k /usr/tests/Kyuafile bin/cp usr.bin/cut

  Obtaining reports of the tests execution
Additional information of the results of the execution can be later extracted from the database by using the various reporting commands of Kyua. For example, the following would extract a plain-text report of the executed tests and show which ones failed:

    $ kyua report

This other example would generate an HTML report ready to be published on a web server, possibly the built-in httpd(8):

    $ kyua report-html --output ~/public_html/tests

For further details on the command-line interface of Kyua, please refer to its manual page kyua(1).

  Test environment considerations
Tests can be invoked as an unprivileged user, in which case tests that require privileges will be skipped. If run as root, an unprivileged user will be used for tests that do not require privileges. For maximal coverage, the standard approach is to invoke tests as root.

Ideally, tests are self-contained and do not either depend on or perturb the host environment, aside from skipping tests when optional facilities are not available. In reality, tests load and unload modules, and do other things that might cause problems. While it is not entirely safe to run tests on a multi-user system, permanent problems or crashes from doing so are viewed as bugs and should be reported.

  Configuring the tests
Some test cases in the NetBSD test suite require the administrator to manually set up some configuration properties before they can run. Unless these properties are defined, the tests that require them will be marked as skipped and thus they will not be really executed.

Test suites are configured by defining the values to their configuration variables in /etc/kyua/kyua.conf. The format of this file is detailed in kyua.conf(5).

The following configuration variables are available in the NetBSD test suite:

fstype
    When set to a filesystem type, restrict tests programs from the /usr/tests/fs/vfs/.

  What to do if something fails?
If there is any failure during the execution of the test suite, please considering reporting it to the NetBSD developers so that the failure can be analyzed and fixed. To do so, either send a message to the appropriate mailing list or file a problem report. For more details please refer to:
•   NetBSD mailing lists: http://www.netbsd.org/mailinglists/
•   NetBSD Problem Reports: http://www.netbsd.org/support/send-pr.html

FILES
/etc/kyua/kyua.conf
    System-wide configuration file for kyua(1).
~/.kyua/kyua.conf
    User-specific configuration file for kyua(1); overrides the system file.
~/.kyua/store.db
    Default database used by Kyua to maintain the data of the executed tests.
/usr/tests/
    Location of the NetBSD test suite.
/usr/tests/Kyuafile
    Top-level test suite definition file.

SEE ALSO
kyua(1), kyua-report(1), kyua-test(1)

HISTORY
The collection of test programs in /usr/tests first appeared in NetBSD 5.0 and has been growing since then.

The tests manual page first appeared in NetBSD 6.0 and was updated in NetBSD 7.0 to describe the execution of the tests with Kyua rather than with ATF.

The ATF testing framework was first distributed with NetBSD 5.0 and the runtime tools of this framework are being phased out in NetBSD 7.0. Note that the libraries that ship with ATF are still in active use and are not deprecated.

The Kyua testing toolkit was first distributed with NetBSD 7.0. The atf-run(1) and atf-report(1) tools were replaced as part of this import to be backwards-compatibility wrappers around kyua(1).

AUTHORS
Julio Merino <jmmv@NetBSD.org>