TESTS(7)

🌈 TESTS(7) 🌈

ok so bestie, welcome to the tests manual page — that's section 7 of the Miscellaneous Information Manual, and yes it's giving "the most useful page nobody reads." Let's fix that 💅

---

✨ NAME ✨

tests — the intro to the FreeBSD Test Suite. That's it, that's the vibe 🎀

---

💖 DESCRIPTION 💖

So the FreeBSD Test Suite is literally a whole collection of automated tests, and it's got two big main character purposes:

• On one hand, it helps developers catch bugs and regressions when they go modifying the source tree. Like, a safety net, fr fr.
• On the other hand, it lets end users (and especially system administrators) verify that fresh installations of the FreeBSD operating system actually behave correctly on their hardware platform — and also make sure the system doesn't suffer from regressions during regular operation and maintenance. Obsessed with a proactive queen 🫶

You'll find the FreeBSD Test Suite chilling in the /usr/tests hierarchy.

This page tells you how to run the test suite and how to configure some of its optional features. If you wanna learn how to write the tests, that's a different page — go see atf(7).

🌸 Installing the test suite 🌸

If the /usr/tests directory is missing (tragic), then you'll have to enable the build of the test suite, rebuild your system, and install the results. Here's how you do it:

• Set WITH_TESTS=yes in your /etc/src.conf file (go read src.conf(5) for the details, iykyk)
• Rebuild the system as described in build(7)

That's it. Slay.

🦋 When to run the tests? 🦋

Before we dive into the details of how to run the test suite, here are some scenarios where you should run it:

• After a fresh installation of FreeBSD, to ensure that the system works correctly on your hardware platform. 🖥️
• After an upgrade of FreeBSD to a different version, to ensure that the new code works well on your hardware platform AND that the upgrade didn't introduce regressions in your configuration.
• After modifying the source tree, to detect any new bugs and/or regressions.
• Periodically — maybe from a cron(8) job — to ensure that any changes to the system (like the installation of third-party packages, or manual modifications to configuration files) don't introduce unexpected failures. ⏰

⭐ Running the tests ⭐

By default, Kyua looks for tests in the current directory. To run the whole test suite, you've got two options:

Either use the -k option to specify the top-level Kyuafile:

$ kyua test -k /usr/tests/Kyuafile

or just change to the test suite root before running Kyua:

$ cd /usr/tests
$ kyua test

The above will iterate through all test programs in /usr/tests recursively, execute them, store their results and debugging data in Kyua's database (by default in ~/.kyua/store/), and print a summary of the results. That summary includes a brief count of all total tests run and how many of them failed. Love a lil report card 📋

It's also possible to restrict which tests to run by providing their names, or a portion of their path, on the command line. For example, this would execute all of the tests provided for the cp(1) and stat(1) utilities:

$ cd /usr/tests
$ kyua test bin/cp usr.bin/stat

And this would execute only one of the two test programs provided for stat(1):

$ cd /usr/tests
$ kyua test usr.bin/stat/stat_test

This one would execute just a single test case:

$ cd /usr/tests
$ kyua test usr.bin/stat/stat_test:t_flag

And finally, this would execute that test case in debug mode:

$ cd /usr/tests
$ kyua debug -p usr.bin/stat/stat_test:t_flag

The -p option tells Kyua to pause before cleanup so you can inspect the temporary directory and better understand why the test failed. Very "let me look at the crime scene" of it 🔍

ngl, some tests may require root privileges to execute:

$ cd /usr/tests
$ kyua debug usr.bin/stat/stat_test:h_flag
usr.bin/stat/stat_test:h_flag  ->  skipped: Requires root privileges
$ sudo kyua debug usr.bin/stat/stat_test:h_flag
[...]
usr.bin/stat/stat_test:h_flag  ->  passed

Conversely — plot twist — some tests will only work correctly if run as an unprivileged user. This will normally be noted in the test's metadata, causing Kyua to automatically drop privileges before running the test. Considerate king 👑

🧚 Obtaining reports of the tests execution 🧚

You can pull additional info about the test results using Kyua's various reporting commands. For example, the following prints a plain-text report of the tests executed in the latest test run and shows which ones failed:

$ kyua report --verbose

To show the results of an arbitrary test run, use the -r option to specify which results file to read:

$ kyua report --verbose \
    -r ~/.kyua/store/results.usr_tests.20260417-173009-335060.db

Keep in mind that if the tests were run as root, the results will have been stored in root's kyua directory, and the easiest way to access them will be to run the report command as root as well:

$ cd /usr/tests
$ sudo kyua test usr.bin/stat
$ sudo kyua report --verbose

This example would generate an HTML report, ready to be published on a web server:

$ 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). 💜

🌷 Configuring the tests 🌷

Some test cases in the FreeBSD Test Suite require manual configuration by the administrator before they can be run. Unless certain properties are defined, the tests that require them will be skipped.

Test suites are configured by defining 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 FreeBSD Test Suite:

• allow_devfs_side_effects — If defined, enables tests that may destroy and recreate semipermanent device nodes, like disk devices. Without this variable, tests may still create and destroy device nodes that are normally transient, like /dev/tap* and /dev/pts*, as long as they clean them up afterwards. However, tests that require this variable have a relaxed cleanup requirement; they must recreate any devices that they destroyed, but not necessarily with the same devnames. ⚠️
• allow_sysctl_side_effects — Enables tests that change globally significant sysctl(8) variables. The tests will undo any changes in their cleanup phases.
• allow_network_access — Enables tests that need to access the network the test host is connected to. Such tests may require properly configured Internet access. 🌐
• disks — Must be set to a space delimited list of disk device nodes. Tests that need destructive access to disks must use these devices. Tests are not required to preserve any data present on these disks. 💀 (yes, destructive, we said it)
• fibs — Must be set to a space delimited list of FIBs (routing tables). Tests that need to modify a routing table may use any of these. Tests will cleanup any new routes that they create.

💅 What to do if something fails? 💅

If there's any failure during the execution of the test suite, please consider reporting it to the FreeBSD developers so 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:

• FreeBSD Mailing Lists: https://lists.freebsd.org/
• Problem Reporting: https://www.freebsd.org/support/

---

🎀 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/logs/ — Default location of Kyua debug logs (one .log file per test run).
• ~/.kyua/store/ — Default location of Kyua test results (one .db file per test run).
• /usr/tests/ — Location of the FreeBSD Test Suite.
• /usr/tests/Kyuafile — Top-level test suite definition file.

---

🔥 SEE ALSO 🔥

kyua(1), atf(7), build(7), development(7)

---

💜 HISTORY 💜

The FreeBSD Test Suite first appeared in FreeBSD 10.1 and was installed by default in FreeBSD 11.0. Glow-up era ✨

The tests manual page first appeared in NetBSD 6.0 and was later ported to FreeBSD 10.1.

The test driver, kyua(1), was imported as part of the base system in FreeBSD 13.0 — previously it was available only in ports(7). She graduated 🎓

---

👑 AUTHORS 👑

Julio Merino <jmmv@FreeBSD.org>

---

and that's the whole page, bestie — you ate 💖

cute lil sign-off: this beauty comes from Debian, dated April 17, 2026. go forth and run your tests fr fr 🦋