ct
MODULE
MODULE SUMMARY
DESCRIPTION
Main user interface for the Common Test framework.
This module implements the command line interface for running tests and some basic functions for common test case issues such as configuration and logging.
Test Suite Support Macros
The config macro is defined in ct.hrl. This macro should be used to retrieve information from the Config variable sent to all test cases. It is used with two arguments, where the first is the name of the configuration variable you wish to retrieve, and the second is the Config variable supplied to the test case.
Possible configuration variables include:
data_dir - Data file directory.
priv_dir - Scratch file directory.
Whatever added by init_per_suite/1 or init_per_testcase/2 in the test suite.
DATA TYPES
EXPORTS
abort_current_testcase(Reason) -> ok | {error, no_testcase_running}
Types:
When calling this function, the currently executing test case will be aborted. It is the user's responsibility to know for sure which test case is currently executing. The function is therefore only safe to call from a function which has been called (or synchronously invoked) by the test case.
Reason, the reason for aborting the test case, is printed in the test case log.
add_config(Callback, Config) -> ok | {error, Reason}
Types:
This function loads configuration variables using the given callback module and configuration string. Callback module should be either loaded or present in the code part. Loaded configuration variables can later be removed using remove_config/2 function.
break(Comment) -> ok | {error, Reason}
Types:
This function will cancel any active timetrap and pause the execution of the current test case until the user calls 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. If a parallel group is executing, break/2 should be called instead.
A cancelled timetrap will not be automatically reactivated after the break, but must be started exlicitly with ct:timetrap/1
In order for the break/continue functionality to work, Common Test must release the shell process controlling stdin. This is done by setting the release_shell start option to true. See the User's Guide for more information.
break(TestCase, Comment) -> ok | {error, Reason}
Types:
This function works the same way as break/1, only the TestCase argument makes it possible to pause a test case executing in a parallel group. The continue/1 function should be used to resume execution of TestCase.
See break/1 for more details.
capture_get() -> ListOfStrings
Types:
Equivalent to capture_get([default]).
capture_get(ExclCategories) -> ListOfStrings
Types:
Return and purge the list of text strings buffered during the latest session of capturing printouts to stdout. With ExclCategories it's possible to specify log categories that should be ignored in ListOfStrings. If ExclCategories = [], no filtering takes place.
See also: capture_start/0, capture_stop/0, log/3.
Start capturing all text strings printed to stdout during execution of the test case.
See also: capture_get/1, capture_stop/0.
Stop capturing text strings (a session started with capture_start/0).
See also: capture_get/1, capture_start/0.
Types:
Print the given Comment in the comment field in the table on the test suite result page.
If called several times, only the last comment is printed. The test case return value {comment,Comment} overwrites the string set by this function.
comment(Format, Args) -> void()
Types:
Print the formatted string in the comment field in the table on the test suite result page.
The Format and Args arguments are used in call to io_lib:format/2 in order to create the comment string. The behaviour of comment/2 is otherwise the same as the comment/1 function (see above for details).
This function must be called in order to continue after a test case (not executing in a parallel group) has called break/1.
Types:
This function must be called in order to continue after a test case has called break/2. If the paused test case, TestCase, executes in a parallel group, this function - rather than continue/0 - must be used in order to let the test case proceed.
decrypt_config_file(EncryptFileName, TargetFileName) -> ok | {error, Reason}
Types:
This function decrypts EncryptFileName, previously generated with encrypt_config_file/2/3. The original file contents is saved in the target file. The encryption key, a string, must be available in a text file named .ct_config.crypt in the current directory, or the home directory of the user (it is searched for in that order).
decrypt_config_file(EncryptFileName, TargetFileName, KeyOrFile) -> ok | {error, Reason}
Types:
This function decrypts EncryptFileName, previously generated with encrypt_config_file/2/3. The original file contents is saved in the target file. The key must have the the same value as that used for encryption.
encrypt_config_file(SrcFileName, EncryptFileName) -> ok | {error, Reason}
Types:
This function encrypts the source config file with DES3 and saves the result in file EncryptFileName. The key, a string, must be available in a text file named .ct_config.crypt in the current directory, or the home directory of the user (it is searched for in that order).
See the Common Test User's Guide for information about using encrypted config files when running tests.
See the crypto application for details on DES3 encryption/decryption.
encrypt_config_file(SrcFileName, EncryptFileName, KeyOrFile) -> ok | {error, Reason}
Types:
This function encrypts the source config file with DES3 and saves the result in the target file EncryptFileName. The encryption key to use is either the value in {key,Key} or the value stored in the file specified by {file,File}.
See the Common Test User's Guide for information about using encrypted config files when running tests.
See the crypto application for details on DES3 encryption/decryption.
Types:
Types:
Terminate a test case with an error message specified by a format string and a list of values (used as arguments to io_lib:format/2).
Equivalent to get_config(Required, undefined, []).
get_config(Required, Default) -> Value
Equivalent to get_config(Required, Default, []).
get_config(Required, Default, Opts) -> ValueOrElement
Types:
Read config data values.
This function returns the matching value(s) or config element(s), given a config variable key or its associated name (if one has been specified with require/2 or a require statement).
Example, given the following config file:
{unix,[{telnet,IpAddr}, {user,[{username,Username}, {password,Password}]}]}.
ct:get_config(unix,Default) ->
[{telnet,IpAddr},
{user, [{username,Username},
{password,Password}]}]
ct:get_config({unix,telnet},Default) -> IpAddr
ct:get_config({unix,user,username},Default) -> Username
ct:get_config({unix,ftp},Default) -> Default
ct:get_config(unknownkey,Default) -> Default
If a config variable key has been associated with a name (by means of require/2 or a require statement), the name may be used instead of the key to read the value:
ct:require(myuser,{unix,user}) -> ok.
ct:get_config(myuser,Default) ->
[{username,Username},
{password,Password}]
If a config variable is defined in multiple files and you want to access all possible values, use the all option. The values will be returned in a list and the order of the elements corresponds to the order that the config files were specified at startup.
If you want config elements (key-value tuples) returned as result instead of values, use the element option. The returned elements will then be on the form {Required,Value}
See also: get_config/1, get_config/2, require/1, require/2.
get_status() -> TestStatus | {error, Reason} | no_tests_running
Types:
Returns status of ongoing test. The returned list contains info about which test case is currently executing (a list of cases when a parallel test case group is executing), as well as counters for successful, failed, skipped, and total test cases so far.
get_target_name(Handle) -> {ok, TargetName} | {error, Reason}
Types:
get_timetrap_info() -> {Time, Scale}
Types:
Read info about the timetrap set for the current test case. Scale indicates if Common Test will attempt to automatically compensate timetraps for runtime delays introduced by e.g. tools like cover.
install(Opts) -> ok | {error, Reason}
Types:
Install config files and event handlers.
Run this function once before first test.
Example:
install([{config,["config_node.ctc","config_user.ctc"]}]).
Note that this function is automatically run by the ct_run program.
Types:
Performs the listenv command on the given telnet connection and returns the result as a list of Key-Value pairs.
Equivalent to log(default, 50, Format, []).
Types:
Equivalent to log(Category, Importance, Format, Args).
Types:
Equivalent to log(Category, Importance, Format, Args).
log(Category, Importance, Format, Args) -> ok
Types:
Printout from a test case to the log file.
This function is meant for printing a string directly from a test case to the test case log file.
Default Category is default, default Importance is ?STD_IMPORTANCE, and default value for Args is [].
Please see the User's Guide for details on Category and Importance.
make_priv_dir() -> ok | {error, Reason}
Types:
If the test has been started with the create_priv_dir option set to manual_per_tc, in order for the test case to use the private directory, it must first create it by calling this function.
Types:
Sends a asynchronous notification of type Name with Datato the common_test event manager. This can later be caught by any installed event manager.
See also: gen_event(3).
Equivalent to pal(default, 50, Format, []).
Types:
Equivalent to pal(Category, Importance, Format, Args).
Types:
Equivalent to pal(Category, Importance, Format, Args).
pal(Category, Importance, Format, Args) -> ok
Types:
Print and log from a test case.
This function is meant for printing a string from a test case, both to the test case log file and to the console.
Default Category is default, default Importance is ?STD_IMPORTANCE, and default value for Args is [].
Please see the User's Guide for details on Category and Importance.
parse_table(Data) -> {Heading, Table}
Types:
Parse the printout from an SQL table and return a list of tuples.
The printout to parse would typically be the result of a select command in SQL. The returned Table is a list of tuples, where each tuple is a row in the table.
Heading is a tuple of strings representing the headings of each column in the table.
Equivalent to print(default, 50, Format, []).
Types:
Equivalent to print(Category, Importance, Format, Args).
Types:
Equivalent to print(Category, Importance, Format, Args).
print(Category, Importance, Format, Args) -> ok
Types:
Printout from a test case to the console.
This function is meant for printing a string from a test case to the console.
Default Category is default, default Importance is ?STD_IMPORTANCE, and default value for Args is [].
Please see the User's Guide for details on Category and Importance.
reload_config(Required) -> ValueOrElement
Types:
Reload config file which contains specified configuration key.
This function performs updating of the configuration data from which the given configuration variable was read, and returns the (possibly) new value of this variable.
Note that if some variables were present in the configuration but are not loaded using this function, they will be removed from the configuration table together with their aliases.
remove_config(Callback, Config) -> ok
Types:
This function removes configuration variables (together with their aliases) which were loaded with specified callback module and configuration string.
require(Required) -> ok | {error, Reason}
Types:
Check if the required configuration is available. It is possible to specify arbitrarily deep tuples as Required. Note that it is only the last element of the tuple which can be a list of SubKeys.
Example 1: require the variable myvar:
ok = ct:require(myvar).
In this case the config file must at least contain:
{myvar,Value}.
Example 2: require the key myvar with subkeys sub1 and sub2:
ok = ct:require({myvar,[sub1,sub2]}).
In this case the config file must at least contain:
{myvar,[{sub1,Value},{sub2,Value}]}.
Example 3: require the key myvar with subkey sub1 with subsub1:
ok = ct:require({myvar,sub1,sub2}).
In this case the config file must at least contain:
{myvar,[{sub1,[{sub2,Value}]}]}.
See also: get_config/1, get_config/2, get_config/3, require/2.
require(Name, Required) -> ok | {error, Reason}
Types:
Check if the required configuration is available, and give it a name. The semantics for Required is the same as in required/1 except that it is not possible to specify a list of SubKeys.
If the requested data is available, the sub entry will be associated with Name so that the value of the element can be read with get_config/1,2 provided Name instead of the whole Required term.
Example: Require one node with a telnet connection and an ftp connection. Name the node a:
ok = ct:require(a,{machine,node}).
All references to this node may then use the node name. E.g. you can fetch a file over ftp like this:
ok = ct:ftp_get(a,RemoteFile,LocalFile).
For this to work, the config file must at least contain:
{machine,[{node,[{telnet,IpAddr},{ftp,IpAddr}]}]}.
The behaviour of this function changed radically in common_test
1.6.2. In order too keep some backwards compatability it is still possible
to do:
ct:require(a,{node,[telnet,ftp]}).
This will associate the name a with the top level node entry.
For this to work, the config file must at least contain:
{node,[{telnet,IpAddr},{ftp,IpAddr}]}.
See also: get_config/1, get_config/2, get_config/3, require/1.
Types:
run(TestDir, Suite, Cases) -> Result
Types:
Run the given test case(s).
Requires that ct:install/1 has been run first.
Suites (*_SUITE.erl) files must be stored in TestDir or TestDir/test. All suites will be compiled when test is run.
Types:
Run tests as specified by the combination of options in Opts. The options are the same as those used with the ct_run program. Note that here a TestDir can be used to point out the path to a Suite. Note also that the option testcase corresponds to the -case option in the ct_run program. Configuration files specified in Opts will be installed automatically at startup.
TestRunnerPid is returned if release_shell == true (see break/1 for details).
Reason indicates what type of error has been encountered.
run_testspec(TestSpec) -> Result
Types:
Run test specified by TestSpec. The terms are the same as those used in test specification files.
Reason indicates what type of error has been encountered.
Types:
This function, similar to timer:sleep/1, suspends the test case for specified time. However, this function also multiplies Time with the 'multiply_timetraps' value (if set) and under certain circumstances also scales up the time automatically if 'scale_timetraps' is set to true (default is false).
Start CT in interactive mode.
From this mode all test case support functions can be executed directly from the erlang shell. The interactive mode can also be started from the OS command line with ct_run -shell [-config File...].
If any functions using "required config data" (e.g. telnet or ftp functions) are to be called from the erlang shell, config data must first be required with ct:require/2.
Example:
> ct:require(unix_telnet, unix).
ok
> ct_telnet:open(unix_telnet).
{ok,<0.105.0>}
> ct_telnet:cmd(unix_telnet, "ls .").
{ok,["ls","file1 ...",...]}
step(TestDir, Suite, Case) -> Result
Types:
step(TestDir, Suite, Case, Opts) -> Result
Types:
Step through a test case with the debugger. If the config option has been given, breakpoints will be set also on the configuration functions in Suite.
See also: run/3.
Types:
Sends a synchronous notification of type Name with Datato the common_test event manager. This can later be caught by any installed event manager.
See also: gen_event(3).
testcases(TestDir, Suite) -> Testcases | {error, Reason}
Types:
Types:
Use this function to set a new timetrap for the running test case. If the argument is Func, the timetrap will be triggered when this function returns. Func may also return a new Time value, which in that case will be the value for the new timetrap.
userdata(TestDir, Suite) -> SuiteUserData | {error, Reason}
Types:
userdata(TestDir, Suite, Case::GroupOrCase) -> TCUserData | {error, Reason}
Types: