We see any plugin startup messages during suite configuration, where
initialization is called once to query plugin features. No need to be verbose
and show these messages once again in the first test.
If a test fails in a timeout or a test failure, longjmp() is used to restore
the thread context and handle test failure. However, there might be unreleased
resources, namely locks, which prevent the library to clean up properly after
finishing the test.
By using thread cleanup handlers, we can release any test subject internal or
test specific external resources on test failure. We do so by calling all
registered cleanup handlers.
Instead of using weak symbols, we use dlsym() on Windows to find an arbitrary
symbol in libtest to detect its linkage. Instead of creating the associated
hashtable in the test runner, we maintain it in libstrongswan, making it
significantly simpler.
Due to the removal of pthread_once, we manually create the seed for
chunk_hash(). With the new testable functions interface, this won't work for
the hashtable initiated using __attribute__((constructor)). Enforce seeding
before creating that hashtable.
By setting the environment variable TESTS_STRONGSWAN_CONF, the unit tests can
be asked to load a configuration file, thus enabling the tester to make use of
the usual configuration settings.
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
The test runner deinit function often cancels all threads from the pool. This
operation might hang on error conditions, hence we should include that hook in
the test timeout to fail properly.
Because GCC does not adhere to the priorities defined for constructors
when building with --enable-monolithic (not sure if it was just luck
that it worked in non-monolithic mode - anyway, it's not very portable)
function registration would fail because the hashtable would not be
created yet.
Other users may make use of the noinst libtest.la helper library to implement
unit tests. For libstrongswan, tests.[ch] provide the configuration for test
runner to perform unit tests in a simple manner.
Calling load() incrementally does not really work as dependencies
wouldn't be resolved properly if a required feature was to be provided
by a plugin that is loaded later with a separate call to load().
Tobias Brunner