The
For more information on how to write test cases and for examples, please see the Test Server User's Guide.
The following functions are supposed to be used inside a test suite.
This function is equivalent to
This will make the test suite fail with a given reason, or
with
Sets up a time trap for the current process. An expired
timetrap kills the process with reason
If the current process is trapping exits, it will not be killed
by the exit signal with reason
This function cancels a timetrap. This must be done before the timetrap expires.
This function returns the scale factor by which all timetraps
are scaled. It is normally 1, but can be greater than 1 if
the test_server is running
This function suspends the calling process for at least the
supplied number of milliseconds. There are two major reasons
why you should use this function instead of
This function suspends the calling process for at least the
supplied number of milliseconds. The function behaves the same
way as
Theese functions convert
Use this function when you want to
Formats output just like
Typically, the test person don't want to see everything a
test suite outputs, but is merely interested in if the test
cases succeeded or not, which the test server tells him. If he
would like to see more, he could manually change the threshold
values by using the
These functions makes it possible to capture all output to
stdout from a process started by the test suite. The list of
characters captured can be purged by using
This function will empty and return all the messages currently in the calling process' message queue.
This function measures the time (in seconds) it takes to call a certain function. The function call is not caught within a catch.
Calls MFA or Fun N times. Useful for extensive testing of a sensitive function.
Repeatedly evaluates the given function until it succeeds (doesn't crash) M times. If, after N times, M successful attempts have not been accomplished, the process crashes with reason {m_out_of_n_failed, {R,left_to_do}}, where R indicates how many cases that was still to be successfully completed.
For example:
Tries to run tricky_test_case() up to 4 times, and is
happy if it succeeds once.
Tries running clock_sanity_check() up to 8 times,and
allows the function to fail once. This might be useful if
clock_sanity_check/0 is known to fail if the clock crosses an
hour boundary during the test (and the up to 8 test runs could
never cross 2 boundaries)
Spawns a new process that calls MFA. The call is considered
successful if the call crashes with the gives reason
(
Returns a unique filename starting with
This function will cancel all timetraps and pause the
execution of the test case until the user executes the
When the
"Here is a comment, it could e.g. instruct to pull out a card"
-----------------------------
Continue with --> test_server:continue(). ]]>
The user can now interact with the erlang node, and when
ready call
Note that this function can not be used if the test is
executed with
This function must be called in order to continue after a
test case has called
Nodes from an earlier OTP release can normally not be started
if the test server hasn't been started in compatibility mode
(see the
You must make sure that nodes started by the shielded node never communicate directly with the test server node.
Slave nodes always communicate with the test server node; therefore, never start slave nodes from the shielded node, always start peer nodes.
This functions starts a node, possibly on a remote machine,
and guarantees cross architecture transparency. Type is set to
either
This functions stops a node previously started with
This function test whether the emulator is commercially supported emulator. The tests for a commercially supported emulator could be more stringent (for instance, a commercial release should always contain documentation for all applications).
This function test whether the release given by
Caution: This function may not be called from the
Checks whether the module is natively compiled or not
Checks an applications .app file for obvious errors. The following is checked:
Checks an applications .appup file for obvious errors. The following is checked:
The given String will occur in the comment field of the table on the HTML result page. If called several times, only the last comment is printed. comment/1 is also overwritten by the return value {comment,Comment} from a test case or by fail/1 (which prints Reason as a comment).
The following functions must be exported from a test suite module.
This function must return the test specification for the test suite module. The syntax of a test specification is described in the Test Server User's Guide.
This function is called before all other test cases in the
suite.
If this function fails, all test cases in the suite will be skipped.
This function is called after the last test case in the suite, and can be used to clean up whatever the test cases have done. The return value is ignored.
This function is called before each test case. The
This function is called after each test case, and can be used to clean up whatever the test case has done. The return value is ignored.
The documentation clause (argument
The specification clause (argument
The execution clause (argument
You can return
You can return
If the execution clause returns anything else, it is
considered a success, unless it is
A conf test case is a group of test cases with an init and a cleanup function. The init and cleanup functions are also test cases, but they have special rules:
There are some macros defined in the
The config macro, is used to
retrieve information from the
Possible configuration variables include:
Examples of the
The line and line_trace macros are deprecated, see below.
In the past, ERTS did not produce line numbers when generating
stacktraces, test_server was thus unable to provide them when reporting
test failures. It had instead two different mecanisms to do it: either by
using the