607e7f6147fd3f36a1990f8c16524653b5ee6157 |
|
04-Jan-2018 |
Phil Carmody <phil@dovecot.fi> |
lib/lib-test: restore DOVECOT_SRAND feature in DEBUG builds
Add a deterministic PRNG, an ability to force its use, and an
ability to re-use the same sequence later.
Since proper random numbers have been forced into use, making
reproducable tests isn't quite as easy as it used to be, it's 3 steps
rather than 2. When seeing an intermittent test failure:
- rerun the tests with environmental variable DOVECOT_SRAND=kiss
- upon seeing a new failure case, note the seed logged at the failure
- debug using DOVECOT_SRAND=<that number>
In non-DEBUG builds, there's no trace of this code, and the
randomisation that is an inherent part of many tests remains
non-reproduceable.
Works with all of the RNG preferences, getrandom/urandom/arc4.
Signed-off-by: Phil Carmody <phil@dovecot.fi> |
bd1e1a9720ce4617f7d97be75cffc45e905bb791 |
|
10-Aug-2016 |
Phil Carmody <phil@dovecot.fi> |
lib-test: test-exit helper to stop valgrind complaining about fork()s
fork()s that want to _exit() will cause valgrind's full memory leak
checker to complain a lot - this performs a quick cleanup first.
Before:
phil@phil:~/repos/dovecot-core$ valgrind --trace-children=yes --leak-check=full --show-leak-kinds=all src/lib/test-lib --match unix
==19576== total heap usage: 4 allocs, 0 frees, 17,858 bytes allocated
istream unix ......................................................... : ok
0 / 1 tests failed
==19575== total heap usage: 7 allocs, 7 frees, 19,327 bytes allocated
After:
phil@phil:~/repos/dovecot-core$ valgrind --trace-children=yes --leak-check=full --show-leak-kinds=all src/lib/test-lib --match unix
istream unix ......................................................... : ok
==4993== total heap usage: 4 allocs, 4 frees, 17,858 bytes allocated
0 / 1 tests failed
==4992== total heap usage: 7 allocs, 7 frees, 19,327 bytes allocated
Signed-off-by: Phil Carmody <phil@dovecot.fi> |
d48ce437e36df095b4c8299d84d6eeb20c280994 |
|
08-Aug-2016 |
Phil Carmody <phil@dovecot.fi> |
lib-test: enable naming of tests, such that only a subset is run
How to use these will become clear in a subsequent patch. Even if you
don't want to name tests, the macros can reduce redundancy in the code,
as the list of test function prototypes and the list of test functions
to call become the same lists, expanded through 2 different macros.
Signed-off-by: Phil Carmody <phil@dovecot.fi> |
0e0a294cfa87a8e44f29997cac48fd5030767b2b |
|
08-Aug-2016 |
Phil Carmody <phil@dovecot.fi> |
lib-test: improve expected error handling
If we expect a specific error string, then when we see it, suppress it.
We do not suppress errors expected by count, because if we get unexpected
errors, then we do not want them suppressed, and we have no way of
distinguishing between the expected and unexpected errors.
This of course favours the use of the expected string version of the helper,
but alas that's not always usable, as you can only expect one at a time.
Additionally, if we failed to see an expected message, then when we no longer
expect to see it, reset the expected message state to not cascade further
test assertion failures.
Signed-off-by: Phil Carmody <phil@dovecot.fi>
Conflicts:
src/lib-test/test-common.c |
7d442a685dd22588aceb75e630b69e28357acaae |
|
15-Jun-2015 |
Phil Carmody <phil@dovecot.fi> |
lib-test: let tests invoke i_warning/i_error behaviour
Error-handling paths should be testable too. Permit a test case to register
that a known number of warnings/errors are to be expected, and to verify
that those warnings did occur afterwards. Too many messages will fail the
test exactly as it did in the past, they're unexpected messages. However,
too few messages will also cause the test case to fail.
Signed-off-by: Phil Carmody <phil@dovecot.fi> |
16c9a74e2ddc8b3b0d0c50d5fe5bcdf25c3f93a5 |
|
28-Nov-2014 |
Phil Carmody <phil@dovecot.fi> |
lib-test: more delicate *assert() behaviour when doing fatal tests
We shouldn't be i_asserting ourselves when we're in the state of wanting a
test to fail. Therefore instead test_assert to get the assert message, and
ensure that the success flag is cleared to get the FAILED at the end.
Signed-off-by: Phil Carmody <phil@dovecot.fi> |
a4e0dc5b1c4ff4caccfb928e3be0542905b0ec9a |
|
30-Jul-2014 |
Phil Carmody <phil@dovecot.fi> |
lib-test: permit tests of fatal conditions
Some functions have no mechanism of reporting an error, and mustn't continue,
so fatality is the only way out. (E.g. memory allocation failures.)
This addition is for those situations. Semantics of failure tests are very
different from normal tests:
- The test function must have the following prototype:
enum fatal_test_state test_fatal_things(int index);
- The index it will be called with starts at 0, and increments each time.
- It must call test_start() at the start of its first call.
- Apart from its final call, it must call a function it expects to trap the
fatal error handler. If that fails to trap, it must return FATAL_TEST_FAILURE
- After returning FATAL_TEST_FAILURE, it will continue to be called as normal.
- When there are no more tests to perform, it must clean up, call test_end()
and return FATAL_TEST_FINISHED. It will not be called again.
- If it detects errors in this protocol, it must not i_assert(), as that will
be treated as an expected fatal, it must return FATAL_TEST_ABORT. It will
then not be called again. It must not call test_end() in this case.
Signed-off-by: Phil Carmody <phil@dovecot.fi> |
00a34f888890caf56c66ff4d15445cab58ebd8d2 |
|
02-Jul-2014 |
Phil Carmody <phil@dovecot.fi> |
lib-test: test-common - add test_out_quiet() to reduce verbosity
Like test_out() but only prints anything if success is false.
This makes it quite much like test_assert(), except that it
doesn't print the code fragment, it prints a custom string.
However, it still counts as a test in the total count, unlike
test_assert*()s.
Signed-off-by: Phil Carmody <phil@dovecot.fi> |
a2818f9ffaec7813cd9529592856b4c10aaedd00 |
|
27-Jun-2014 |
Phil Carmody <phil@dovecot.fi> |
lib-test: use the new srand() tracking helpers to aid debugging
We can only be sure we know the entirity of the stream of numbers returned
by rand if rand_set_seed has been called precisely once, as after that we
can't be sure when it was called a 2nd or further time. However, at least
we can know that that has happened. (Likewise, any calls to srand() will
disturb the flow.)
Most unit test cases should be simple enough that there should be only one
seeding.
Signed-off-by: Phil Carmody <phil@dovecot.fi> |