freebsd-src/tests
Zhenlei Huang 76df3c57a0 ifconfig: Redo fix vlan/vlanproto reconfiguration
When the if_vlan(4) interface has not been fully configured, i.e., a
bare interface without a physical interface associated with it,
retrieving the current settings of it and unconditionally overwriting
`params` will result in losing vlandev settings in `params`. That will
lead to failing to associate the if_vlan(4) interface with the requested
physical interface and the false report 'both vlan and vlandev must be
specified'.

Fix that by checking if the vlan interface has been fully configured.

The basic VLAN test is slightly modified to cover this case.

PR:		279181
Reviewed by:	kp
Tested by:	Mike Tancsa <mike@sentex.net>
Fixes:		b82b8055ad ifconfig: fix vlan/vlanproto reconfiguration
MFC after:	3 days
Differential Revision:	https://reviews.freebsd.org/D45283
2024-05-22 00:35:01 +08:00
..
atf_python tests: move atf_python/sys/ into the tests package 2024-04-19 14:48:37 -04:00
ci Add preliminary in-tree CI infrastructure for developers 2024-04-18 20:02:24 +02:00
etc Remove $FreeBSD$: one-line sh pattern 2023-08-16 11:55:03 -06:00
examples Remove $FreeBSD$: one-line sh pattern 2023-08-16 11:55:03 -06:00
freebsd_test_suite Remove $FreeBSD$: two-line .h pattern 2023-08-16 11:54:16 -06:00
include include: Add tests for N2867. 2023-09-07 06:40:14 +00:00
sys ifconfig: Redo fix vlan/vlanproto reconfiguration 2024-05-22 00:35:01 +08:00
__init__.py testing: Add basic atf support to pytest. 2022-06-25 19:25:15 +00:00
conftest.py Testing: add framework for the kernel unit tests. 2023-04-14 15:47:55 +00:00
Kyuafile Remove $FreeBSD$: one-line lua tag 2023-08-16 11:55:34 -06:00
Makefile include: Add tests for N2867. 2023-09-07 06:40:14 +00:00
Makefile.depend Remove $FreeBSD$: one-line sh pattern 2023-08-16 11:55:03 -06:00
Makefile.inc0 Remove $FreeBSD$: one-line sh pattern 2023-08-16 11:55:03 -06:00
README Remove $FreeBSD$: one-line bare tag 2023-08-16 11:55:20 -06:00

src/tests: The FreeBSD test suite
=================================

Usage of the FreeBSD test suite:
(1)  Run the tests:
       kyua test -k /usr/tests/Kyuafile
(2)  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/.

--