diff options
Diffstat (limited to 'lib/eunit/doc/overview.edoc')
| -rw-r--r-- | lib/eunit/doc/overview.edoc | 17 |
1 files changed, 9 insertions, 8 deletions
diff --git a/lib/eunit/doc/overview.edoc b/lib/eunit/doc/overview.edoc index df716cdeea..dc9f858812 100644 --- a/lib/eunit/doc/overview.edoc +++ b/lib/eunit/doc/overview.edoc @@ -578,7 +578,7 @@ results for equality, if testing is enabled. If the values are not equal, an informative exception will be generated; see the `assert' macro for further details. -`assertEqual' is more suitable than than `assertMatch' when the +`assertEqual' is more suitable than `assertMatch' when the left-hand side is a computed value rather than a simple pattern, and gives more details than `?assert(Expect =:= Expr)'. @@ -690,9 +690,12 @@ it like `debugMsg'. The result is always `ok'.</dd> <dt>`debugVal(Expr)'</dt> <dd>Prints both the source code for `Expr' and its current value. E.g., `?debugVal(f(X))' might be displayed as "`f(X) = 42'". (Large terms are -shown truncated.) The result is always the value of `Expr', so this -macro can be wrapped around any expression to display its value when -the code is compiled with debugging enabled.</dd> +truncated to the depth given by the macro `EUNIT_DEBUG_VAL_DEPTH', which +defaults to 15 but can be overridden by the user.) The result is always the +value of `Expr', so this macro can be wrapped around any expression to +display its value when the code is compiled with debugging enabled.</dd> +<dt>`debugVal(Expr, Depth)'</dt> +<dd>Like `debugVal(Expr)', but prints terms truncated to the given depth.</dd> <dt>`debugTime(Text,Expr)'</dt> <dd>Prints `Text' and the wall clock time for evaluation of `Expr'. The result is always the value of `Expr', so this macro can be wrapped @@ -885,7 +888,7 @@ the timeout is exceeded, the unfinished tests will be forced to terminate. Note that if a timeout is set around a fixture, it includes the time for setup and cleanup, and if the timeout is triggered, the entire fixture is abruptly terminated (without running the -cleanup).</dd> +cleanup). The default timeout for an individual test is 5 seconds.</dd> <dt>`{inorder, Tests}'</dt> <dd>Runs the specified tests in strict order. Also see `{inparallel, Tests}'. By default, tests are neither marked as `inorder' or @@ -907,7 +910,6 @@ the test set is finished, regardless of the outcome (success, failures, timeouts, etc.). To make the descriptions simpler, we first list some definitions: -<center> <table border="0" cellspacing="4"> <tr> <td>`Setup'</td><td>`() -> (R::any())'</td> @@ -928,7 +930,6 @@ To make the descriptions simpler, we first list some definitions: <td>`Where'</td><td>`local | spawn | {spawn, Node::atom()}'</td> </tr> </table> -</center> (these are explained in more detail further below.) The following representations specify fixture handling for test sets: @@ -993,7 +994,7 @@ specified node. `local' means that the current process will handle both setup/teardown and running the tests - the drawback is that if a test times out so that the process is killed, the <em>cleanup will not be performed</em>; hence, avoid this for persistent fixtures such as file -operations. In general, 'local' should only be used when: +operations. In general, `local' should only be used when: <ul> <li>the setup/teardown needs to be executed by the process that will run the tests;</li> |