1
<?xml version="1.0" encoding="latin1" ?>
2
<!DOCTYPE erlref SYSTEM "erlref.dtd">
9
<holder>Ericsson AB, All Rights Reserved</holder>
12
The contents of this file are subject to the Erlang Public License,
13
Version 1.1, (the "License"); you may not use this file except in
14
compliance with the License. You should have received a copy of the
15
Erlang Public License along with this software. If not, it can be
16
retrieved online at http://www.erlang.org/.
18
Software distributed under the License is distributed on an "AS IS"
19
basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See
20
the License for the specific language governing rights and limitations
23
The Initial Developer of the Original Code is Ericsson AB.
26
<title>The Test Server Controller</title>
27
<prepared>Siri Hansen</prepared>
28
<responsible></responsible>
34
<file>test_server_ctrl_ref.sgml</file>
36
<module>test_server_ctrl</module>
37
<modulesummary>This module provides a low level interface to the Test Server.</modulesummary>
39
<p>The <c>test_server_ctrl</c> module provides a low level
40
interface to the Test Server. This interface is normally
41
not used directly by the tester, but through a framework built
42
on top of <c>test_server_ctrl</c>.
44
<p>Common Test is such a framework, well suited for automated
45
black box testing of target systems of any kind (not necessarily
46
implemented in Erlang). Common Test is also a very useful tool for
47
white box testing Erlang programs and OTP applications.
48
Please see the Common Test User's Guide and reference manual for
51
<p>If you want to write your own framework, some more information
52
can be found in the chapter "Writing your own test server
53
framework" in the Test Server User's Guide. Details about the
54
interface provided by <c>test_server_ctrl</c> follows below.
59
<name>start() -> Result</name>
60
<name>start(ParameterFile) -> Result</name>
61
<fsummary>Starts the test server.</fsummary>
63
<v>Result = ok | {error, {already_started, pid()}</v>
64
<v>ParameterFile = atom() | string()</v>
67
<p>This function starts the test server. If the parameter file
68
is given, it indicates that the target is remote. In that case
69
the target node is started and a socket connection is
70
established between the controller and the target node.
72
<p>The parameter file is a text file containing key-value
73
tuples. Each tuple must be followed by a dot-newline
74
sequence. The following key-value tuples are allowed:
77
<tag><c>{type,PlatformType}</c></tag>
78
<item>This is an atom indicating the target platform type,
79
currently supported: <c>PlatformType = vxworks</c> <br></br>
82
<tag><c>{target,TargetHost}</c></tag>
83
<item>This is the name of the target host, can be atom or
88
<tag><c>{slavetargets,SlaveTargets}</c></tag>
89
<item>This is a list of available hosts where slave nodes
90
can be started. The hostnames are given as atoms or strings.
92
Optional, default <c>SlaveTargets = []</c></item>
93
<tag><c>{longnames,Bool}</c></tag>
94
<item>This indicates if longnames shall be used, i.e. if the
95
<c>-name</c> option should be used for the target node
96
instead of <c>-sname</c> <br></br>
97
Optional, default <c>Bool = false</c></item>
98
<tag><c>{master, {MasterHost, MasterCookie}}</c></tag>
99
<item>If target is remote and the target node is started as
100
a slave node, this option indicates which master and
101
cookie to use. The given master
102
will also be used as master for slave nodes started with
103
<c>test_server:start_node/3</c>. It is expected that the
104
<c>erl_boot_server</c> is started on the master node before
105
the <c>test_server_ctrl:start/1</c> function is called.
107
Optional, if not given the test server controller node
108
is used as master and the <c>erl_boot_server</c> is
109
automatically started.</item>
114
<name>stop() -> ok</name>
115
<fsummary>Stops the test server immediately.</fsummary>
117
<p>This stops the test server (both controller and target) and
118
all its activity. The running test suite (if any) will be
123
<name>add_dir(Name, Dir) -> ok</name>
124
<name>add_dir(Name, Dir, Pattern) -> ok</name>
125
<name>add_dir(Name, [Dir|Dirs]) -> ok</name>
126
<name>add_dir(Name, [Dir|Dirs], Pattern) -> ok</name>
127
<fsummary>Add a directory to the job queue.</fsummary>
130
<d>The jobname for this directory.</d>
132
<d>The directory to scan for test suites.</d>
133
<v>Dirs = [term()]</v>
134
<d>List of directories to scan for test suites.</d>
135
<v>Pattern = term()</v>
136
<d>Suite match pattern. Directories will be scanned for Pattern_SUITE.erl files.</d>
139
<p>Puts a collection of suites matching (*_SUITE) in given
140
directories into the job queue. <c>Name</c> is an arbitrary
141
name for the job, it can be any erlang term. If <c>Pattern</c>
142
is given, only modules matching <c>Pattern*</c> will be added.</p>
146
<name>add_module(Mod) -> ok</name>
147
<name>add_module(Name, [Mod|Mods]) -> ok</name>
148
<fsummary>Add a module to the job queue with or without a given name.</fsummary>
151
<v>Mods = [atom()]</v>
152
<d>The name(s) of the module(s) to add.</d>
154
<d>Name for the job.</d>
157
<p>This function adds a module or a list of modules, to the
158
test servers job queue. <c>Name</c> may be any Erlang
159
term. When <c>Name</c> is not given, the job gets the name of
164
<name>add_case(Mod, Case) -> ok</name>
165
<fsummary>Adds one test case to the job queue.</fsummary>
168
<d>Name of the module the test case is in.</d>
169
<v>Case = atom() </v>
170
<d>Function name of the test case to add.</d>
173
<p>This function will add one test case to the job queue. The
174
job will be given the module's name.</p>
178
<name>add_case(Name, Mod, Case) -> ok</name>
179
<fsummary>Equivalent to add_case/2, but with specified name.</fsummary>
181
<v>Name = string()</v>
182
<d>Name to use for the test job.</d>
185
<p>Equivalent to <c>add_case/2</c>, but the test job will get
186
the specified name.</p>
190
<name>add_cases(Mod, Cases) -> ok</name>
191
<fsummary>Adds a list of test cases to the job queue.</fsummary>
194
<d>Name of the module the test case is in.</d>
195
<v>Cases = [Case] </v>
196
<v>Case = atom() </v>
197
<d>Function names of the test cases to add.</d>
200
<p>This function will add one or more test cases to the job
201
queue. The job will be given the module's name.</p>
205
<name>add_cases(Name, Mod, Cases) -> ok</name>
206
<fsummary>Equivalent to add_cases/2, but with specified name.</fsummary>
208
<v>Name = string()</v>
209
<d>Name to use for the test job.</d>
212
<p>Equivalent to <c>add_cases/2</c>, but the test job will get
213
the specified name.</p>
217
<name>add_spec(TestSpecFile) -> ok | {error, nofile}</name>
218
<fsummary>Adds a test specification file to the job queue.</fsummary>
220
<v>TestSpecFile = string()</v>
221
<d>Name of the test specification file</d>
224
<p>This function will add the content of the given test
225
specification file to the job queue. The job will be given the
226
name of the test specification file, e.g. if the file is
227
called <c>test.spec</c>, the job will be called <c>test</c>.
229
<p>See the reference manual for the test server application
230
for details about the test specification file.</p>
234
<name>add_dir_with_skip(Name, [Dir|Dirs], Skip) -> ok</name>
235
<name>add_dir_with_skip(Name, [Dir|Dirs], Pattern, Skip) -> ok</name>
236
<name>add_module_with_skip(Mod, Skip) -> ok</name>
237
<name>add_module_with_skip(Name, [Mod|Mods], Skip) -> ok</name>
238
<name>add_case_with_skip(Mod, Case, Skip) -> ok</name>
239
<name>add_case_with_skip(Name, Mod, Case, Skip) -> ok</name>
240
<name>add_cases_with_skip(Mod, Cases, Skip) -> ok</name>
241
<name>add_cases_with_skip(Name, Mod, Cases, Skip) -> ok</name>
242
<fsummary>Same purpose as functions listed above, but with extra Skip argument.</fsummary>
244
<v>Skip = [SkipItem]</v>
245
<d>List of items to be skipped from the test.</d>
246
<v>SkipItem = {Mod,Comment} | {Mod,Case,Comment} | {Mod,Cases,Comment}</v>
248
<d>Test suite name.</d>
249
<v>Comment = string()</v>
250
<d>Reason why suite or case is being skipped.</d>
251
<v>Cases = [Case]</v>
253
<d>Name of test case function.</d>
256
<p>These functions add test jobs just like the add_dir, add_module,
257
add_case and add_cases functions above, but carry an additional
258
argument, Skip. Skip is a list of items that should be skipped
259
in the current test run. Test job items that occur in the Skip
260
list will be logged as SKIPPED with the associated Comment.</p>
264
<name>add_tests_with_skip(Name, Tests, Skip) -> ok</name>
265
<fsummary>Adds different types of jobs to the run queue.</fsummary>
268
<d>The jobname for this directory.</d>
269
<v>Tests = [TestItem]</v>
270
<d>List of jobs to add to the run queue.</d>
271
<v>TestItem = {Dir,all,all} | {Dir,Mods,all} | {Dir,Mod,Cases}</v>
273
<d>The directory to scan for test suites.</d>
276
<d>Test suite name.</d>
277
<v>Cases = [Case]</v>
279
<d>Name of test case function.</d>
280
<v>Skip = [SkipItem]</v>
281
<d>List of items to be skipped from the test.</d>
282
<v>SkipItem = {Mod,Comment} | {Mod,Case,Comment} | {Mod,Cases,Comment}</v>
283
<v>Comment = string()</v>
284
<d>Reason why suite or case is being skipped.</d>
287
<p>This function adds various test jobs to the test_server_ctrl
288
job queue. These jobs can be of different type (all or specific suites
289
in one directory, all or specific cases in one suite, etc). It is also
290
possible to get particular items skipped by passing them along in the
291
Skip list (see the add_*_with_skip functions above).</p>
295
<name>abort_current_testcase(Reason) -> ok | {error,no_testcase_running}</name>
296
<fsummary>Aborts the test case currently executing.</fsummary>
298
<v>Reason = term()</v>
299
<d>The reason for stopping the test case, which will be printed in the log.</d>
302
<p>When calling this function, the currently executing test case will be aborted.
303
It is the user's responsibility to know for sure which test case is currently
304
executing. The function is therefore only safe to call from a function which
305
has been called (or synchronously invoked) by the test case.</p>
309
<name>set_levels(Console, Major, Minor) -> ok</name>
310
<fsummary>Sets the levels of I/O.</fsummary>
312
<v>Console = integer()</v>
313
<d>Level for I/O to be sent to console.</d>
314
<v>Major = integer()</v>
315
<d>Level for I/O to be sent to the major logfile.</d>
316
<v>Minor = integer()</v>
317
<d>Level for I/O to be sent to the minor logfile.</d>
320
<p>Determines where I/O from test suites/test server will
321
go. All text output from test suites and the test server is
322
tagged with a priority value which ranges from 0 to 100, 100
323
being the most detailed. (see the section about log files in
324
the user's guide). Output from the test cases (using
325
<c>io:format/2</c>) has a detail level of 50. Depending on the
326
levels set by this function, this I/O may be sent to the
327
console, the major log file (for the whole test suite) or to
328
the minor logfile (separate for each test case).
330
<p>All output with detail level:</p>
331
<list type="bulleted">
332
<item>Less than or equal to <c>Console</c> is displayed on
333
the screen (default 1)
335
<item>Less than or equal to <c>Major</c> is logged in the
336
major log file (default 19)
338
<item>Greater than or equal to <c>Minor</c> is logged in the
339
minor log files (default 10)
342
<p>To view the currently set thresholds, use the
343
<c>get_levels/0</c> function.</p>
347
<name>get_levels() -> {Console, Major, Minor}</name>
348
<fsummary>Returns the current levels.</fsummary>
350
<p>Returns the current levels. See <c>set_levels/3</c> for
355
<name>jobs() -> JobQueue</name>
356
<fsummary>Returns the job queue.</fsummary>
358
<v>JobQueue = [{list(), pid()}]</v>
361
<p>This function will return all the jobs currently in the job
366
<name>multiply_timetraps(N) -> ok</name>
367
<fsummary>All timetraps started after this will be multiplied by N.</fsummary>
369
<v>N = integer() | infinity</v>
372
<p>This function should be called before a test is started
373
which requires extended timetraps, e.g. if extensivie tracing
374
is used. All timetraps started after this call will be
375
multiplied by <c>N</c>.</p>
379
<name>cover(Application,Analyse) -> ok</name>
380
<name>cover(CoverFile,Analyse) -> ok</name>
381
<name>cover(App,CoverFile,Analyse) -> ok</name>
382
<fsummary>Informs the test_server controller that next test shall run with code coverage analysis.</fsummary>
384
<v>Application = atom()</v>
385
<d>OTP application to cover compile</d>
386
<v>CoverFile = string()</v>
387
<d>Name of file listing modules to exclude from or include in cover compilation. The filename must include full path to the file.</d>
388
<v>Analyse = details | overview</v>
391
<p>This function informs the test_server controller that next
392
test shall run with code coverage analysis. All timetraps will
393
automatically be multiplied by 10 when cover i run.
395
<p><c>Application</c> and <c>CoverFile</c> indicates what to
396
cover compile. If <c>Application</c> is given, the default is
397
that all modules in the <c>ebin</c> directory of the
398
application will be cover compiled. The <c>ebin</c> directory
399
is found by adding <c>ebin</c> to
400
<c>code:lib_dir(Application)</c>.
402
<p>A <c>CoverFile</c> can have the following entries:</p>
404
{exclude, all | ExcludeModuleList}.
405
{include, IncludeModuleList}. </code>
406
<p>Note that each line must end with a full
407
stop. <c>ExcludeModuleList</c> and <c>IncludeModuleList</c>
408
are lists of atoms, where each atom is a module name.
410
<p>If both an <c>Application</c> and a <c>CoverFile</c> is
411
given, all modules in the application are cover compiled,
412
except for the modules listed in <c>ExcludeModuleList</c>. The
413
modules in <c>IncludeModuleList</c> are also cover compiled.
415
<p>If a <c>CoverFile</c> is given, but no <c>Application</c>,
416
only the modules in <c>IncludeModuleList</c> are cover
419
<p><c>Analyse</c> indicates the detail level of the cover
420
anlysis. If <c>Analyse = details</c>, each cover compiled
421
module will be analysed with
422
<c>cover:analyse_to_file/1</c>. If <c>Analyse = overview</c>
423
an overview of all cover compiled modules is created, listing
424
the number of covered and not covered lines for each module.
426
<p>If the test following this call starts any slave or peer
427
nodes with <c>test_server:start_node/3</c>, the same cover
428
compiled code will be loaded on all nodes. If the loading
429
fails, e.g. if the node runs an old version of OTP, the node
430
will simply not be a part of the coverage analysis. Note that
431
slave or peer nodes must be stopped with
432
<c>test_server:stop_node/1</c> for the node to be part of the
433
coverage analysis, else the test server will not be able to
434
fetch coverage data from the node.
436
<p>When the test is finished, the coverage analysis is
437
automatically completed, logs are created and the cover
438
compiled modules are unloaded. If another test is to be run
439
with coverage analysis, <c>test_server_ctrl:cover/2/3</c> must
445
<name>cross_cover_analyse(Level) -> ok</name>
446
<fsummary>Analyse cover data collected from all tests</fsummary>
448
<v>Level = details | overview</v>
451
<p>Analyse cover data collected from all tests. The modules
452
analysed are the ones listed in the cross cover file
453
<c>cross.cover</c> in the current directory of the test
455
<p>The modules listed in the <c>cross.cover</c> file are
456
modules that are heavily used by other applications than the
457
one they belong to. This function should be run after all
458
tests are completed, and the result will be stored in a file
459
called cross_cover.html in the run.<timestamp>
460
directory of the application the modules belong to.
462
<p>The <c>cross.cover</c> file contains elements like this:</p>
464
{App,Modules}. </pre>
465
<p>where <c>App</c> can be an application name or the atom
466
<c>all</c>. The application (or all applications) will cover
467
compile the listed <c>Modules</c>.
472
<name>trc(TraceInfoFile) -> ok | {error, Reason}</name>
473
<fsummary>Starts call trace on target and slave nodes</fsummary>
475
<v>TraceInfoFile = atom() | string()</v>
476
<d>Name of a file defining which functions to trace and how</d>
479
<p>This function starts call trace on target and on slave or
480
peer nodes that are started or will be started by the test
483
<p>Timetraps are not extended automatically when tracing is
484
used. Use <c>multiply_timetraps/1</c> if necessary.
486
<p>Note that the trace support in the test server is in a very
487
early stage of the implementation, and thus not yet as
488
powerful as one might wish for.
490
<p>The trace information file specified by the
491
<c>TraceInfoFile</c> argument is a text file containing one or
492
more of the following elements:
494
<list type="bulleted">
495
<item><c>{SetTP,Module,Pattern}.</c></item>
496
<item><c>{SetTP,Module,Function,Pattern}.</c></item>
497
<item><c>{SetTP,Module,Function,Arity,Pattern}.</c></item>
498
<item><c>ClearTP.</c></item>
499
<item><c>{ClearTP,Module}.</c></item>
500
<item><c>{ClearTP,Module,Function}.</c></item>
501
<item><c>{ClearTP,Module,Function,Arity}.</c></item>
504
<tag><c>SetTP = tp | tpl</c></tag>
505
<item>This is maps to the corresponding functions in the
506
<c>ttb</c> module in the <c>observer</c>
507
application. <c>tp</c> means set trace pattern on global
508
function calls. <c>tpl</c> means set trace pattern on local
509
and global function calls.
511
<tag><c>ClearTP = ctp | ctpl | ctpg</c></tag>
512
<item>This is maps to the corresponding functions in the
513
<c>ttb</c> module in the <c>observer</c>
514
application. <c>ctp</c> means clear trace pattern (i.e. turn
515
off) on global and local function calls. <c>ctpl</c> means
516
clear trace pattern on local function calls only and <c>ctpg</c>
517
means clear trace pattern on global function calls only.
519
<tag><c>Module = atom()</c></tag>
520
<item>The module to trace
522
<tag><c>Function = atom()</c></tag>
523
<item>The name of the function to trace
525
<tag><c>Arity = integer()</c></tag>
526
<item>The arity of the function to trace
528
<tag><c>Pattern = [] | match_spec()</c></tag>
529
<item>The trace pattern to set for the module or
530
function. For a description of the match_spec() syntax,
531
please turn to the User's guide for the runtime system
532
(erts). The chapter "Match Specification in Erlang" explains
533
the general match specification language.
536
<p>The trace result will be logged in a (binary) file called
537
<c>NodeName-test_server</c> in the current directory of the
538
test server controller node. The log must be formatted using
539
<c>ttb:format/1/2</c>.
541
<p>This is valid for all targets except the OSE/Delta target
542
for which all nodes will be logged and automatically formatted
543
in one single text file called <c>allnodes-test_server</c>.</p>
547
<name>stop_trace() -> ok | {error, not_tracing}</name>
548
<fsummary>Stops tracing on target and slave nodes.</fsummary>
550
<p>This function stops tracing on target, and on slave or peer
551
nodes that are currently running. New slave or peer nodes will
552
no longer be traced after this.</p>
558
<title>FUNCTIONS INVOKED FROM COMMAND LINE</title>
559
<p>The following functions are supposed to be invoked from the
560
command line using the <c>-s</c> option when starting the erlang
565
<name>run_test(CommandLine) -> ok</name>
566
<fsummary>Runs the tests specified on the command line.</fsummary>
568
<v>CommandLine = FlagList</v>
571
<p>This function is supposed to be invoked from the
572
commandline. It starts the test server, interprets the
573
argument supplied from the commandline, runs the tests
574
specified and when all tests are done, stops the test server
575
and returns to the Erlang prompt.
577
<p>The <c>CommandLine</c> argument is a list of command line
578
flags, typically <c>['KEY1', Value1, 'KEY2', Value2, ...]</c>.
579
The valid command line flags are listed below.
581
<p>Under a UNIX command prompt, this function can be invoked like this:
583
<c>erl -noshell -s test_server_ctrl run_test KEY1 Value1 KEY2 Value2 ... -s erlang halt</c></p>
584
<p>Or make an alias (this is for unix/tcsh) <br></br>
585
<c>alias erl_test 'erl -noshell -s test_server_ctrl run_test \\!* -s erlang halt'</c></p>
586
<p>And then use it like this <br></br>
587
<c>erl_test KEY1 Value1 KEY2 Value2 ...</c> <br></br>
589
<p>The valid command line flags are</p>
591
<tag><c>DIR dir</c></tag>
592
<item>Adds all test modules in the directory <c>dir</c> to
595
<tag><c>MODULE mod</c></tag>
596
<item>Adds the module <c>mod</c> to the job queue.
598
<tag><c>CASE mod case</c></tag>
599
<item>Adds the case <c>case</c> in module <c>mod</c> to the
602
<tag><c>SPEC spec</c></tag>
603
<item>Runs the test specification file <c>spec</c>.
605
<tag><c>SKIPMOD mod</c></tag>
606
<item>Skips all test cases in the module <c>mod</c></item>
607
<tag><c>SKIPCASE mod case</c></tag>
608
<item>Skips the test case <c>case</c> in module <c>mod</c>.
610
<tag><c>NAME name</c></tag>
611
<item>Names the test suite to something else than the
612
default name. This does not apply to <c>SPEC</c> which keeps
615
<tag><c>PARAMETERS parameterfile</c></tag>
616
<item>Specifies the parameter file to use when starting
619
<tag><c>COVER app cover_file analyse</c></tag>
620
<item>Indicates that the test should be run with cover
621
alanysis. <c>app</c>, <c>cover_file</c> and <c>analyse</c>
622
corresponds to the parameters to
623
<c>test_server_ctrl:cover/3</c>. If no cover file is used,
624
the atom <c>none</c> should be given.
626
<tag><c>TRACE traceinfofile</c></tag>
627
<item>Specifies a trace information file. When this option
628
is given, call tracing is started on the target node and all
629
slave or peer nodes that are started. The trace information
630
file specifies which modules and functions to trace. See the
631
function <c>trc/1</c> above for more information about the
640
<title>FRAMEWORK CALLBACK FUNCTIONS</title>
641
<p>A test server framework can be defined by setting the
642
environment variable <c>TEST_SERVER_FRAMEWORK</c> to a module
643
name. This module will then be framework callback module, and it
644
must export the following function:</p>
648
<name>get_suite(Mod,Func) -> TestCaseList</name>
649
<fsummary>Get subcases.</fsummary>
653
<v>TestCaseList = [,SubCase]</v>
656
<p>This function is called before a test case is started. The
657
purpose is to retrieve a list of subcases. The default
658
behaviour of this function should be to call
659
<c>Mod:Func(suite)</c> and return the result from this call.</p>
663
<name>init_tc(Mod,Func,Args) -> {ok,Args}</name>
664
<fsummary>Preparation for a test case.</fsummary>
668
<v>Args = [tuple()]</v>
669
<d>Normally Args = [Config]</d>
672
<p>This function is called when a test case is started. It is
673
called on the process executing the test case function
674
(<c>Mod:Func</c>). Typical use of this function can be to alter
675
the input parameters to the test case function (<c>Args</c>) or
676
to set properties for the executing process.</p>
680
<name>end_tc(Mod,Func,Args) -> ok</name>
681
<fsummary>Cleanup after a test case.</fsummary>
685
<v>Args = [tuple()]</v>
686
<d>Normally Args = [Config]</d>
689
<p>This function is called when a test case is completed. It is
690
called on the process where the test case function
691
(<c>Mod:Func</c>) was executed. Typical use of this function can
692
be to clean up stuff done by <c>init_tc/3</c>.</p>
696
<name>report(What,Data) -> ok</name>
697
<fsummary>Progress report for test.</fsummary>
703
<p>This function is called in order to keep the framework upto
704
date about the progress of the test. This is useful e.g. if the
705
framework implements a GUI where the progress information is
706
constantly updated. The following can be reported:
708
<p><c>What = tests_start, Data = {Name,NumCases}</c> <br></br>
709
<c>What = tests_done, Data = {Ok,Failed,Skipped}</c> <br></br>
710
<c>What = tc_start, Data = {Mod,Func}</c> <br></br>
711
<c>What = tc_done, Data = {Mod,Func,Result}</c></p>
715
<name>error_notification(Mod, Case, Args, Error) -> ok</name>
716
<fsummary>Inform framework of crashing testcase.</fsummary>
719
<d>Test suite name.</d>
721
<d>Name of test case function.</d>
722
<v>Args = [tuple()]</v>
723
<d>Normally Args = [Config]</d>
724
<v>Error = {Reason,Location}</v>
725
<v>Reason = term()</v>
726
<d>Reason for termination.</d>
727
<v>Location = unknown | [{Mod,Case,Line}]</v>
728
<d>Last known position in Mod before termination.</d>
729
<v>Line = integer()</v>
730
<d>Line number in file Mod.erl.</d>
733
<p>This function is called as the result of testcase Mod:Case failing
734
with Reason at Location. The function is intended mainly to aid
735
specific logging or error handling in the framework application. Note
736
that for Location to have relevant values (i.e. other than unknown),
737
the <c>line</c> macro or <c>test_server_line</c> parse transform must
738
be used. For details, please see the section about test suite line numbers
739
in the <c>test_server</c> reference manual page.</p>
743
<name>warn(What) -> boolean()</name>
744
<fsummary>Ask framework if test server should issue a warning for What.</fsummary>
746
<v>What = processes | nodes</v>
749
<p>The test server checks the number of processes and nodes
750
before and after the test is executed. This function is a
751
question to the framework if the test server should warn when
752
the number of processes or nodes has changed during the test
753
execution. If <c>true</c> is returned, a warning will be written
754
in the test case minor log file.</p>
758
<name>target_info() -> InfoStr</name>
759
<fsummary>Print info about the target system to the test case log.</fsummary>
761
<v>InfoStr = string() | ""</v>
764
<p>The test server will ask the framework for information about
765
the test target system and print InfoStr in the test case
766
log file below the host information.</p>
added
removed
lib/test_server/doc/src/test_server_ctrl.xml
