zeek/testing/btest
2021-01-11 11:48:45 -08:00
..
Baseline Merge branch 'master' into topic/vern/lambda-copy-semantics 2021-01-11 11:48:45 -08:00
Baseline.dup cleaner approach for localizing errors associated with duplicated ASTs: virtualize GetLocationInfo 2021-01-07 15:14:22 -08:00
Baseline.inline Update alternative plugins.hooks baselines 2020-12-13 13:24:47 -08:00
bifs Additional use of btest-diff --binary 2020-12-06 20:19:52 -08:00
broker BrokerStore <-> Zeek Tables: support complex indices 2020-11-17 14:48:10 +00:00
core GH-1321: Prevent compounding of connection_status_update event timers 2020-12-08 11:20:02 -08:00
coverage Update Python invocations to explicit python3 2020-11-25 14:57:09 -08:00
doc General btest cleanup 2020-08-11 11:26:22 -07:00
Files
language tests added for new capture-by-reference closure semantics & errors 2021-01-04 14:38:12 -08:00
opt inlining of Zeek script functions 2020-11-19 16:16:59 -08:00
plugins Update minimum required CMake to 3.5 2020-12-01 22:13:52 -08:00
scripts Merge branch 'master' into topic/vern/script-inlining 2021-01-06 22:08:29 -08:00
signatures GH-779: Add "udp-state" signature condition 2020-10-09 13:43:17 -07:00
supervisor General btest cleanup 2020-08-11 11:26:22 -07:00
Traces Merge remote-tracking branch 'origin/topic/johanna/1323' 2020-12-22 11:00:59 -08:00
.gitignore
btest.cfg cleaner approach for localizing errors associated with duplicated ASTs: virtualize GetLocationInfo 2021-01-07 15:14:22 -08:00
Makefile Rename aux/ to auxil/ 2020-06-04 15:18:44 -07:00
random.seed
README More bro-to-zeek renaming in the unit tests 2019-05-16 02:27:54 -05:00

This a test suite of small "unit tests" that verify individual pieces of Zeek
functionality.  They all utilize BTest, a simple framework/driver for
writing unit tests.  More information about BTest can be found at
https://github.com/zeek/btest

The test suite's BTest configuration is handled through the
``btest.cfg`` file.  Of particular interest is the "TestDirs" settings,
which specifies which directories BTest will recursively search for
test files.

Significant Subdirectories
==========================

* Baseline/
	Validated baselines for comparison against the output of each
	test on future runs. If the new output differs from the Baseline
	output, then the test fails.

* Traces/
	Packet captures utilized by the various BTest tests.

* scripts/
	This hierarchy of tests emulates the hierarchy of the Zeek scripts/
	directory.

* coverage/
	This collection of tests relates to checking whether we're covering
	everything we want to in terms of tests, documentation, and which
	scripts get loaded in different Zeek configurations.  These tests are
	more prone to fail as new Zeek scripts are developed and added to the
	distribution -- checking the individual test's comments is the best
	place to check for more details on what exactly the test is checking
	and hints on how to fix it when it fails.

Running Tests
=============

Either use the ``make all`` or ``make brief`` ``Makefile`` targets, or
run ``btest`` directly with desired options/arguments.  Examples:

* btest <no arguments>
	If you simply execute btest in this directory with no arguments,
	then all directories listed as "TestDirs" in btest.cfg will be
	searched recursively for test files.


* btest <btest options> test_directory
	You can specify a directory on the command line to run just the
	tests contained in that directory. This is useful if you wish to
	run all of a given type of test, without running all the tests
	there are. For example, "btest scripts" will run all of the Zeek
	script unit tests.


* btest <btest options> test_directory/test_file
	You can specify a single test file to run just that test. This
	is useful when testing a single failing test or when developing
	a new test.

Adding Tests
=============

See either the `BTest documentation
<https://github.com/zeek/btest>`_ or the existing unit
tests for examples of what they actually look like.  The essential
components of a new test include:

* A test file in one of the subdirectories listed in the ``TestDirs``
  of the ``btest.cfg`` file.

* If the unit test requires a known-good baseline output against which
  future tests will be compared (via ``btest-diff``), then that baseline
  output will need to live in the ``Baseline`` directory.  Manually
  adding that is possible, but it's easier to just use the ``-u`` or
  ``-U`` options of ``btest`` to do it for you (using ``btest -d`` on a
  test for which no baseline exists will show you the output so it can
  be verified first before adding/updating the baseline output).

If you create a new top-level testing directory for collecting related
tests, then you'll need to add it to the list of ``TestDirs`` in
``btest.cfg``. Do this only if your test really doesn't fit logically in
any of the extant directories.