test_server

This function is equivalent to os:type/0. It is kept for backwards compatibility.

This will make the test suite fail with a given reason, or with suite_failed if no reason was given. Use this function if you want to terminate a test case, as this will make it easier to read the log- and HTML files. Reason will appear in the comment field in the HTML log.

Sets up a time trap for the current process. An expired timetrap kills the process with reason timetrap_timeout. The returned handle is to be given as argument to timetrap_cancel before the timetrap expires. If Timeout is an integer, it is expected to be milliseconds.

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 cover, using a larger amount of scheduler threads than the amount of logical processors on the system, running under purify, valgrind or in a debug-compiled emulator. The scale factor can be used if you need to scale you own timeouts in test cases with same factor as the test_server uses.

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 timer:sleep, the first being that the module timer may be unavailable at the time the test suite is run, and the second that it also accepts floating point numbers.

This function suspends the calling process for at least the supplied number of milliseconds. The function behaves the same way as test_server:sleep/1, only MSecs will be multiplied by the 'multiply_timetraps' value, if set, and also automatically scaled up if 'scale_timetraps' is set to true (which it is by default).

Theese functions convert N number of hours, minutes or seconds into milliseconds.

Use this function when you want to test_server:sleep/1 for a number of seconds, minutes or hours(!).

Formats output just like io:format but sends the formatted string to a logfile. If the urgency value, Pri, is lower than some threshold value, it will also be written to the test person's console. Default urgency is 50, default threshold for display on the console is 1.

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 test_server_ctrl:set_levels/3 function.

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 capture_get.

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:

m_out_of_n(1,4,fun() -> tricky_test_case() end)
Tries to run tricky_test_case() up to 4 times, and is happy if it succeeds once.

m_out_of_n(7,8,fun() -> clock_sanity_check() end)
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 (Crash) or any reason if not specified. The call must terminate within the given time (default infinity), or it is considered a failure.

Returns a unique filename starting with Stem with enough extra characters appended to make up a unique filename. The filename returned is guaranteed not to exist in the filesystem at the time of the call.

Comment is a string which will be written in the shell, e.g. explaining what to do.

This function will cancel all timetraps and pause the execution of the test case until the user executes the continue/0 function. It gives the user the opportunity to interact with the erlang node running the tests, e.g. for debugging purposes or for manually executing a part of the test case.

When the break/1 function is called, the shell will look something like this:

   --- SEMIAUTOMATIC TESTING ---
   The test case executes on process <0.51.0>


   "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 test_server:continue().

Note that this function can not be used if the test is executed with ts:run/0/1/2/3/4 in batch mode.

This function must be called in order to continue after a test case has called break/1.

Fun is executed in a process on a temporarily created hidden node with a proxy for communication with the test server node. The node is called a shielded node (should have been called a shield node). If Fun is successfully executed, the result is returned. A peer node (see start_node/3) started from the shielded node will be shielded from test server node, i.e. they will not be aware of each other. This is useful when you want to start nodes from earlier OTP releases than the OTP release of the test server node.

Nodes from an earlier OTP release can normally not be started if the test server hasn't been started in compatibility mode (see the +R flag in the erl(1) documentation) of an earlier release. If a shielded node is started in compatibility mode of an earlier OTP release than the OTP release of the test server node, the shielded node can start nodes of an earlier OTP release.

This functions starts a node, possibly on a remote machine, and guarantees cross architecture transparency. Type is set to either slave or peer.

slave means that the new node will have a master, i.e. the slave node will terminate if the master terminates, TTY output produced on the slave will be sent back to the master node and file I/O is done via the master. The master is normally the target node unless the target is itself a slave.

peer means that the new node is an independent node with no master.

Options is a tuplelist which can contain one or more of

This functions stops a node previously started with start_node/3. Use this function to stop any node you start, or the test server will produce a warning message in the test logs, and kill the nodes automatically unless it was started with the {cleanup, false} option.

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 Release (for instance, "r12b_patched") is available on the computer that the test_server controller is running on. Typically, you should skip the test case if not.

Caution: This function may not be called from the suite clause of a test case, as the test_server will deadlock.

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).

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. Config is the configuration which can be modified here. Whatever is returned from this function is given as Config to the test cases.

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 Case argument is the name of the test case, and Config is the configuration which can be modified here. Whatever is returned from this function is given as Config to the test case.

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 doc) can be used for automatic generation of test documentation or test descriptions.

The specification clause (argument spec) shall return an empty list, the test specification for the test case or {skip,Comment}. The syntax of a test specification is described in the Test Server User's Guide.

The execution clause (argument Config) is only called if the specification clause returns an empty list. The execution clause is the real test case. Here you must call the functions you want to test, and do whatever you need to check the result. If something fails, make sure the process crashes or call test_server:fail/0/1 (which also will cause the process to crash).

You can return {skip,Comment} if you decide not to run the test case after all, e.g. if it is not applicable on this platform.

You can return {comment,Comment} if you wish to print some information in the 'Comment' field on the HTML result page.

If the execution clause returns anything else, it is considered a success, unless it is {'EXIT',Reason} or {'EXIT',Pid,Reason} which can't be distinguished from a crash, and thus will be considered a failure.

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: