4330d7272d
* Remove zpool_create_013_neg. FreeBSD doesn't have an equivalent of Solaris's metadevices. GEOM would be the equivalent, but since all geoms are the same from ZFS's perspective, this test would be redundant with zpool_create_012_neg * Remove zpool_create_014_neg. FreeBSD does not support swapping to regular files. * Remove zpool_create_016_pos. This test is redundant with literally every other test that creates a disk-backed pool. * s:/etc/vfstab:/etc/fstab in zpool_create_011_neg * Delete the VTOC-related portion of zpool_create_008_pos. FreeBSD doesn't use VTOC. * Replace dumpadm with dumpon and swap with swapon in multiple tests. * In zpool_create_015_neg, don't require "zpool create -n" to fail. It's reasonable for that variant to succeed, because it doesn't actually open the zvol. * Greatly simplify zpool_create_012_neg. Make it safer, too, but not interfering with the system's regular swap devices. * Expect zpool_create_011_neg to fail (PR 241070) * Delete some redundant cleanup steps in various tests * Remove some unneeeded ATF timeout specifications. The default is fine. PR: 241070 MFC after: 2 weeks Sponsored by: Axcient |
||
---|---|---|
.. | ||
etc | ||
freebsd_test_suite | ||
sys | ||
Kyuafile | ||
Makefile | ||
Makefile.depend | ||
Makefile.inc0 | ||
README |
src/tests: The FreeBSD test suite ================================= To run the FreeBSD test suite: (1) Make sure that kyua is installed: pkg install kyua (2) To run the tests: kyua test -k /usr/tests/Kyuafile (3) To see the test results: kyua report For further information on using the test suite, read tests(7): man tests Description of FreeBSD test suite ================================= The build of the test suite is organized in the following manner: * The build of all test artifacts is protected by the MK_TESTS knob. The user can disable these with the WITHOUT_TESTS setting in src.conf(5). * The goal for /usr/tests/ (the installed test programs) is to follow the same hierarchy as /usr/src/ wherever possible, which in turn drives several of the design decisions described below. This simplifies the discoverability of tests. We want a mapping such as: /usr/src/bin/cp/ -> /usr/tests/bin/cp/ /usr/src/lib/libc/ -> /usr/tests/lib/libc/ /usr/src/usr.bin/cut/ -> /usr/tests/usr.bin/cut/ ... and many more ... * Test programs for specific utilities and libraries are located next to the source code of such programs. For example, the tests for the src/lib/libcrypt/ library live in src/lib/libcrypt/tests/. The tests/ subdirectory is optional and should, in general, be avoided. * The src/tests/ hierarchy (this directory) provides generic test infrastructure and glue code to join all test programs together into a single test suite definition. * The src/tests/ hierarchy also includes cross-functional test programs: i.e. test programs that cover more than a single utility or library and thus don't fit anywhere else in the tree. Consider this to follow the same rationale as src/share/man/: this directory contains generic manual pages while the manual pages that are specific to individual tools or libraries live next to the source code. In order to keep the src/tests/ hierarchy decoupled from the actual test programs being installed --which is a worthy goal because it simplifies the addition of new test programs and simplifies the maintenance of the tree-- the top-level Kyuafile does not know which subdirectories may exist upfront. Instead, such Kyuafile automatically detects, at run-time, which */Kyuafile files exist and uses those directly. Similarly, every directory in src/ that wants to install a Kyuafile to just recurse into other subdirectories reuses this Kyuafile with auto-discovery features. As an example, take a look at src/lib/tests/ whose sole purpose is to install a Kyuafile into /usr/tests/lib/. The goal in this specific case is for /usr/tests/lib/ to be generated entirely from src/lib/. -- $FreeBSD$