This is a framework for testing OTP. The ts
module
implements the interface to all the functionality in the
framework.
The framwork is built on top of the Test Server Controller,
test_server_ctrl
, and provides a high level operator
interface. The main fatures added by the framework are:
More information about the Test Server Framework and how to run test cases can be found in the Test Server User's Guide.
For writing you own test server framework, please turn to the reference manual for the Test Server Controller and chapter named "Writing your own test server framework" in the Test Server User's Guide. guide.
install() -> ok | {error, Reason}
install(TargetSystem) -> ok | {error, Reason}
install(Opts) -> ok | {error, Reason}
install(TargetSystem,Opts) -> ok | {error, Reason}
TargetSystem = {Architecture, TargetHost}
Architecture = atom() or string()
TargetHost = atom() or string()
Opts = list()
Installs and configures the Test Server Framework for
running test suites. If a remote host is to be used, the
TargetSystem
argument must be given so that "cross
installation" can be done. This should be used for testing on
VxWorks or OSE/Delta. Installation is required for any of the
functions in ts
to work.
Opts may be one or more of
{longnames, Bool}
true
or false
(default).
{verbose, Level}
{hosts, Hosts}
{remote, true}
option is given to the test_server:start_node/3
function. Also, if {require_nodenames, Num}
is
contained in a test specification file, the generated
nodenames will be spread over all hosts given in this
Hosts
list. The hostnames are given as atoms or
strings.
{slavetargets, SlaveTarges}
{hosts, Hosts}
because it is used for all slave nodes
- not only the ones started with {remote, true}
. The
hostnames are given as atoms or strings.
{crossroot, TargetErlRoot}
{master, {MasterHost, MasterCookie}}
test_server:start_node/3
. It is expected that the
erl_boot_server
is started on the master node before
the test is run. If this option is not given, the test
server controller node is used as master and the
erl_boot_server
is automatically started.
{erl_start_args, ArgString}
ArgString
will be appended to
the command line when starting the erlang node. Note that
this will only affect the startup of the controller
node, i.e. not the target node or any slave nodes
startet from a test case.
Presents simple help on the functions in ts
. Useful
for quick reference.
Returns the list of available tests. This is actually just a list of all test specification files found by looking up "../*_test/*.spec".
In each ../Name_test/ directory there should be one test specification file named Name.spec.
run() -> ok | {error, Reason}
run(Specs)
run(Specs, Opts)
run(Spec, Module)
run(Spec, Module, Opts)
run(Spec, Module, Case)
run(Spec, Module, Case, Opts)
Specs = Spec | [Spec]
Spec = atom()
Module = atom()
Case = atom()
Opts = [Opt]
Opt = batch | verbose | {verbose, Level} | {vars, Vars} |
keep_topcase | {trace, TraceSpec}
Level = integer(); 0 means silent
Vars = list() of key-value tuples
Reason = term()
This function runs test suite(s)/case(s). To be able to run
any tests, ts:install must first be called to create the
variables
file needed. To run a whole test specification,
only specify the name of the test specification, and all test
suite modules belonging to that test spec will be run. To run
a single module in a test specification, use the Module
argument to specify the name of the module to run and all test
cases in that module will be run, and to run a specified test
case, specify the name of the test case using the Case
argument. If called with no argument, all test specifications
availiable will be run. Use ts:tests/0 to see the available
test specifications.
If the batch
option is not given, a new xterm is
started (unix) when ts:run
is called.
The verbose
option sets the verbosity level for test
server output. This has the same effect as if given to
ts:install/1/2
The vars
option can be used for adding configuration
variables that are not in the variables
file generated
during installation. Can be any of the Opts
valid for
ts:install/1/2
.
The keep_topcase
option forces ts
to keep the
topcase in your test specification file as is. This option can
only be used if you don't give the Module
or
Case
parameters to ts:run
. The
keep_topcase
option is necessary if your topcase
contains anything other than {dir,"../<Name>_test"}
. If
the option is not used, ts
will modify your topcase.
The trace
option is used to turn on call trace on
target and on slave or peer nodes started with
test_server:start_node/3
. TraceSpec
can be the
name of a trace information file, or a list of elememnts like
the ones in a trace information file. Please turn to the
reference manual for test_server_ctrl:trc/1
for details
about the trace information file.
r() -> ok
r(Spec) -> ok
r(Suite) -> ok
r(Suite,Case) -> ok
Spec = string()
Suite = atom()
Case = atom()
This function can be used to run a test suites or test
cases directly, without any of the additional features added
by the test server framework. It is simply a wrapper function
for the add_dir
, add_spec
, add_module
and
add_case
functions in test_server_ctrl
:
r() -> add_dir(".")
r(Spec) -> add_spec(Spec)
r(Suite) -> add_module(Suite)
r(Suite,Case) -> add_case(Suite,Case)
To use this function, it is required that the test suite is
compiled and in the code path of the node where the function
is called. The function can be used without having ts
installed.
save() -> ok | {error, Reason}
save(Name) -> ok | {error, Reason}
Name = atom()
Reason = term()
This function saves the last run of all test suites to a
central location specified by use of the `-env central_log_dir
{dir}' command line option to erl
. Only the last run
of tests are saved, along with the HTML:ized versions of the
modules for quick reference. Logfiles can be viewed by
loading the `index.html' file stored under the
{central_log_dir}/Name dir into an HTML browser.
If Name = release
the log files are saved in a
dedicated directory named after the current OTP release.
update() -> ok | {error, Reason}
Reason = term()
This function unpacks any tar files at central log file location and updates index pages
index() -> ok | {error, Reason}
Reason = term()
This function updates the local index page. This can be useful if a previous test run was not completed and the index is incomplete.
clean() -> ok
clean(all) -> ok
This function cleans up log directories created when
running test cases. clean/0
cleans up all but the last
run of each application. clean/1
cleans up all test
runs found.
estone() -> ok | {error, Reason}
estone(Opts) -> ok
This function runs the EStone test. It is a shortcut for
running the test suite estone_SUITE
in the
kernel
application.
Opts
is the same as the Opts
argument for the
ts:run
functions.
If a data directory contains code which must be compiled before
the test suite is run, a makefile source called
Makefile.src
can be placed in the data directory. This file
will be converted to a valid makefile by ts:run/0/1/2/3/4
.
The reason for generating the makefile is that you can use
variables from the variables
file which was generated by
ts:install/0/1/2
. All occurencies of @Key@
in
Makefile.src
is substituted by the Value
from
{Key,Value}
found in the variables
file. Example:
Cut from variables
:
... {'EMULATOR',"beam"}. {'CFLAGS',"-g -O2"}. {'LD',"$(CC) $(CFLAGS)"}. {'CC',"gcc"}. ...
Makefile.src
for compiling erlang code could look
something like this:
EFLAGS=+debug_info all: ordsets1.@EMULATOR@ ordsets1.@EMULATOR@: ordsets1.erl erlc $(EFLAGS) ordsets1.erl
Makefile.src
for compiling c code could look
something like this:
CC = @CC@ LD = @LD@ CFLAGS = @CFLAGS@ -I@erl_include@ @DEFS@ CROSSLDFLAGS = @CROSSLDFLAGS@ PROGS = nfs_check@exe@ all: $(PROGS) nfs_check@exe@: nfs_check@obj@ $(LD) $(CROSSLDFLAGS) -o nfs_check nfs_check@obj@ @LIBS@ nfs_check@obj@: nfs_check.c $(CC) -c -o nfs_check@obj@ $(CFLAGS) nfs_check.c