| Age | Commit message (Collapse) | Author |
|---|
|
An error during fixture setup means that some tests could not be run,
and therefore needs to be highlighted in the test report. Likewise, a
cleanup failure is often a problem that needs to be looked into.
Since setup and cleanup are not part of any single test in Eunit's
view, I include them as phantom test cases in the report whenever they
fail.
|
|
|
|
|
|
|
|
|
|
* rc/eunit-2.2.0:
Updated to EUnit version 2.2.0
OTP-9505
|
|
New macros assertNotMatch(Guard, Expr), assertNotEqual(Unexpected, Expr),
and assertNotException(Class, Term, Expr).
The debugMsg macro now also prints the pid of the current process.
When testing all modules in a directory, tests in <Module>_tests.erl are
no longer executed twice.
The use of 'regexp' internally has been replaced with 're'.
|
|
Previously the test cases of all test suites (=modules) were put in
one and the same surefire report XML thereby breaking the principle of
least astonishment and making post analysis harder. Assume the
following layout:
src/x.erl
src/y.erl
test/x_tests.erl
test/y_tests.erl
The results for both x_tests and y_tests were written to only one
report grouped under either module x or y (seemingly randomly).
Now two reports, one for module x and one for y are generated.
|
|
When eunit is terminating, a stop message is sent to all listeners and
eunit then waits for *one* result message but previously both
eunit_tty and eunit_surefire sent a response on error. Don't send a
result message from eunit_surefire; let eunit_tty take care of all
result reporting, both positive and negative to avoid race conditions
and inconsistencies.
|
|
Currently, error messages in Eunit Surefire reports are shortened just
like when written to a terminal. However, the space limitations that
constrain terminal output do not apply here, so it's more useful to
include more of the error message. Getting the full error message can
be particularly helpful when an assertMatch fails because of a long
and deep error term.
The new depth of 100 should be enough for most cases, while protecting
against runaway errors.
|
|
warnings/errors in man pages
|
|
|
