1
<?xml version="1.0" encoding="latin1" ?>
2
<!DOCTYPE chapter SYSTEM "chapter.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>Running Test Suites</title>
27
<prepared>Peter Andersson, Kenneth Lundin</prepared>
34
<title>Using the Common Test Framework</title>
36
<p>The Common Test Framework provides a high level
37
operator interface for testing. It adds the following features to
38
the Erlang/OTP Test Server:</p>
41
<item>Automatic compilation of test suites (and help modules).</item>
42
<item>Creation of additional HTML pages for better overview.</item>
43
<item>Single command interface for running all available tests.</item>
44
<item>Handling of configuration files specifying target nodes and
45
other variables.</item>
46
<item>Mode for running multiple independent test sessions in parallel with
47
central control and configuration.</item>
52
<title>Automatic compilation of test suites and help modules</title>
53
<p>When Common Test starts, it will automatically attempt to compile any
54
suites included in the specified tests. If particular
55
suites have been specified, only those suites will be compiled. If a
56
particular test object directory has been specified (meaning all suites
57
in this directory should be part of the test), Common Test runs
58
make:all/1 in the directory to compile the suites.</p>
59
<p>If compilation should fail for one or more suites, the compilation errors
60
are printed to tty and the operator is asked if the test run should proceed
61
without the missing suites, or be aborted. If the operator chooses to proceed,
62
it is noted in the HTML log which tests have missing suites.</p>
63
<p>Any help module (i.e. regular Erlang module with name not ending with
64
"_SUITE") that resides in the same test object directory as a suite
65
which is part of the test, will also be automatically compiled. A help
66
module will not be mistaken for a test suite (unless it has a "_SUITE"
67
name of course). All help modules in a particular test object directory
68
are compiled no matter if all or only particular suites in the directory
69
are part of the test.</p>
73
<title>Running tests from the UNIX command line</title>
75
<p>The script <c>run_test</c> can be used for running tests from
76
the UNIX command line, e.g.
79
<item><c><![CDATA[run_test -config <configfilenames> -dir <dirs>]]></c></item>
80
<item><c><![CDATA[run_test -config <configfilenames> -suite <suiteswithfullpath>]]></c>
82
<item><c><![CDATA[run_test -config <configfilenames> -suite <suitewithfullpath>
83
-case <casenames>]]></c></item>
86
<p><c>$ run_test -config $CFGS/sys1.cfg $CFGS/sys2.cfg -dir $SYS1_TEST $SYS2_TEST</c></p>
87
<p><c>$ run_test -suite $SYS1_TEST/setup_SUITE $SYS2_TEST/config_SUITE</c></p>
88
<p><c>$ run_test -suite $SYS1_TEST/setup_SUITE -case start stop</c></p>
90
<p>Other flags that may be used with <c>run_test</c>:</p>
92
<item><c><![CDATA[-logdir <dir>]]></c>, specifies where the HTML log files are to be written.</item>
93
<item><c>-refresh_logs</c>, refreshes the top level HTML index files.</item>
94
<item><c>-vts</c>, start web based GUI (see below).</item>
95
<item><c>-shell</c>, start interactive shell mode (see below).</item>
96
<item><c><![CDATA[-spec <testspecs>]]></c>, use test specification as input (see below).</item>
97
<item><c>-allow_user_terms</c>, allows user specific terms in a test specification (see below).</item>
98
<item><c>-silent_connections [conn_types]</c>, tells Common Test to suppress printouts for
99
specified connections (see below).</item>
100
<item><c><![CDATA[-stylesheet <css_file>]]></c>, points out a user HTML style sheet (see below).</item>
101
<item><c><![CDATA[-cover <cover_cfg_file>]]></c>, to perform code coverage test (see
102
<seealso marker="cover_chapter#cover">Code Coverage Analysis</seealso>).</item>
103
<item><c><![CDATA[-event_handler <event_handlers>]]></c>, to install
104
<seealso marker="event_handler_chapter#event_handling">event handlers</seealso>.</item>
105
<item><c><![CDATA[-repeat <n>]]></c>, tells Common Test to repeat the tests n times (see below).</item>
106
<item><c><![CDATA[-duration <time>]]></c>, tells Common Test to repeat the tests for duration of time (see below).</item>
107
<item><c><![CDATA[-until <stop_time>]]></c>, tells Common Test to repeat the tests until stop_time (see below).</item>
108
<item><c>-force_stop</c>, on timeout, the test run will be aborted when current test job is finished (see below).</item>
114
<title>Running tests from the Web based GUI</title>
116
<p>The web based GUI, VTS, is started with the <c>run_test</c>
117
script. From the GUI you can load config files, and select
118
directories, suites and cases to run. You can also state the
119
config files, directories, suites and cases on the command line
120
when starting the web based GUI.
124
<item><c>run_test -vts</c></item>
125
<item><c><![CDATA[run_test -vts -config <configfilename>]]></c></item>
126
<item><c><![CDATA[run_test -vts -config <configfilename> -suite <suitewithfullpath>
127
-case <casename>]]></c></item>
130
<p>From the GUI you can run tests and view the result and the logs.
133
<p>Note that <c>run_test -vts</c> will try to open the Common Test start
134
page in an existing web browser window or start the browser if it is
135
not running. Which browser should be started may be specified with
136
the browser start command option:</p>
137
<p><c><![CDATA[run_test -vts -browser <browser_start_cmd>]]></c></p>
139
<p><c><![CDATA[$ run_test -vts -browser 'firefox-2.0.0.3&']]></c></p>
140
<p>Note that the browser must run as a separate OS process or VTS will hang!</p>
141
<p>If no specific browser start command is specified, netscape will
142
be the default browser on UNIX platforms and Internet Explorer on Windows.
143
For the VTS mode to work properly with netscape, make sure the
144
<c>netscape</c> program in your path starts version 7!</p>
148
<title>Running tests from the Erlang shell</title>
150
<p>Common Test provides an Erlang API for running tests. For documentation,
151
please see the <c>ct</c> manual page.</p>
156
<title>Running interactive shell mode</title>
158
<p>You can start an Erlang shell with the necessary paths and
159
with Common Test running in an interactive mode with the <c>run_test</c>
160
script and the <c>-shell</c> option:
163
<item><c>run_test -shell</c></item>
164
<item><c><![CDATA[run_test -shell -config <configfilename>]]></c></item>
167
<p>If no config file is given with the <c>run_test</c> command,
168
a warning will be displayed. If Common Test has been run from the same
169
directory earlier, the same config file(s) will be used
170
again. If Common Test has not been run from this directory before, no
171
config files will be available.</p>
173
<p>From the interactive mode all test case support functions can
174
be executed directly from the erlang shell. This is an
175
experimentation mode useful during test suite development and
178
<p>If any functions using "required config data" (e.g. telnet or
179
ftp functions) are to be called from the erlang shell, config
180
data must first be required with <c>ct:require/[1,2]</c>. This is
181
equivalent to a <c>require</c> statement in the <seealso
182
marker="write_test_chapter#suite">Test Suite Default
183
Data</seealso> or in the <seealso
184
marker="write_test_chapter#info_function">Test Case Info
185
Function</seealso>.</p>
189
> ct:require(a,{unix,[telnet]}).
192
{ok,["ls","file1 ...",...]}</pre>
194
<p>Everything that Common Test normally prints in the test case logs,
195
will in the interactive mode be written to a log named
196
<c>ctlog.html</c> in the <c><![CDATA[ct_run.<timestamp>]]></c>
197
directory. A link to this file will be available in the file
198
named <c>last_interactive.html</c> in the directory from which
199
you executed <c>run_test</c>.</p>
201
<p>If you for some reason want to exit the interactive mode, use
202
the function <c>ct:stop_interactive/0</c>. This shuts down the
203
running <c>ct</c> application. Associations between
204
configuration names and data created with <c>require</c> are
205
consequently deleted. <c>ct:start_interactive/0</c> will get you
206
back into interactive mode, but previous state is not restored.</p>
211
<marker id="test_specifications"></marker>
212
<title>Using test specifications</title>
214
<p>The most expressive way to specify what to test is to use a so
215
called test specification. A test specification is a sequence of
216
Erlang terms. The terms may be declared in a text file or passed
217
to the test server at runtime as a list (see <c>run_testspec/1</c>
218
in the manual page for <c>ct</c>). There are two general types
219
of terms; configuration terms and test specification terms.</p>
220
<p>With configuration terms it is possible to import configuration
221
data (similar to <c>run_test -config</c>), specify HTML log
222
directories (similar to <c>run_test -logdir</c>), give aliases
223
to test nodes and test directories (to make a specification
224
easier to read and maintain), enable code coverage analysis
225
(see the <seealso marker="cover_chapter#cover">Code Coverage
226
Analysis</seealso> chapter) and specify event_handler plugins
227
(see the <seealso marker="event_handler_chapter#event_handling">
228
Event Handling</seealso> chapter).</p>
229
<p>With test specification terms it is possible to state exactly which
230
tests should run and in which order. A test term specifies either
231
one or more suites or one or more test cases. An arbitrary number of test
232
terms may be declared in sequence. A test term can also specify one or
233
more test suites or test cases to be skipped. Skipped suites and cases
234
are not executed and show up in the HTML test log as SKIPPED.</p>
235
<p>Below is the test specification syntax. Test specifications can
236
be used to run tests both in a single test host environment and in
237
a distributed Common Test environment. Node parameters are only relevant in the
238
latter (see the chapter about running Common Test in distributed mode for information).
239
For details on the event_handler term, see the
240
<seealso marker="event_handler_chapter#event_handling">Event Handling</seealso>
244
{node, NodeAlias, Node}.
246
{cover, CoverSpecFile}.
247
{cover, NodeRef, CoverSpecFile}.
249
{config, ConfigFiles}.
250
{config, NodeRefs, ConfigFiles}.
252
{alias, DirAlias, Dir}.
255
{logdir, NodeRefs, LogDir}.
257
{event_handler, EventHandlers}.
258
{event_handler, NodeRefs, EventHandlers}.
259
{event_handler, EventHandlers, InitArgs}.
260
{event_handler, NodeRefs, EventHandlers, InitArgs}.
264
{suites, DirRef, Suites}.
265
{suites, NodeRefs, DirRef, Suites}.
267
{cases, DirRef, Suite, Cases}.
268
{cases, NodeRefs, DirRef, Suite, Cases}.
270
{skip_suites, DirRef, Suites, Comment}.
271
{skip_suites, NodeRefs, DirRef, Suites, Comment}.
273
{skip_cases, DirRef, Suite, Cases, Comment}.
274
{skip_cases, NodeRefs, DirRef, Suite, Cases, Comment}.
280
NodeRef = NodeAlias | Node | master
281
NodeRefs = all_nodes | [NodeRef] | NodeRef
282
CoverSpecFile = string()
283
ConfigFiles = string() | [string()]
287
EventHandlers = atom() | [atom()]
289
DirRef = DirAlias | Dir
290
Suites = atom() | [atom()] | all
291
Cases = atom() | [atom()] | all
292
Comment = string() | ""
296
{logdir, "/home/test/logs"}.
298
{config, "/home/test/t1/cfg/config.cfg"}.
299
{config, "/home/test/t2/cfg/config.cfg"}.
300
{config, "/home/test/t3/cfg/config.cfg"}.
302
{alias, t1, "/home/test/t1"}.
303
{alias, t2, "/home/test/t2"}.
304
{alias, t3, "/home/test/t3"}.
307
{skip_suites, t1, [t1B_SUITE,t1D_SUITE], "Not implemented"}.
308
{skip_cases, t1, t1A_SUITE, [test3,test4], "Irrelevant"}.
309
{skip_cases, t1, t1C_SUITE, [test1], "Ignore"}.
311
{suites, t2, [t2B_SUITE,t2C_SUITE]}.
312
{cases, t2, t2A_SUITE, [test4,test1,test7]}.
314
{skip_suites, t3, all, "Not implemented"}.
316
<p>The example specifies the following:</p>
318
<item>The specified logdir directory will be used for storing
319
the HTML log files (in subdirectories tagged with node name,
320
date and time).</item>
321
<item>The variables in the specified test system config files will be
322
imported for the test.</item>
323
<item>Aliases are given for three test system directories. The suites in
324
this example are stored in "/home/test/tX/test".</item>
325
<item>The first test to run includes all suites for system t1. Excluded from
326
the test are however the t1B and t1D suites. Also test cases test3 and
327
test4 in t1A as well as the test1 case in t1C are excluded from
329
<item>Secondly, the test for system t2 should run. The included suites are
330
t2B and t2C. Included are also test cases test4, test1 and test7 in suite
331
t2A. Note that the test cases will be executed in the specified order.</item>
332
<item>Lastly, all suites for systems t3 are to be completely skipped and this
333
should be explicitly noted in the log files.</item>
335
<p>It is possible for the user to provide a test specification that
336
includes (for Common Test) unrecognizable terms. If this is desired,
337
the <c>-allow_user_terms</c> flag should be used when starting tests with
338
<c>run_test</c>. This forces Common Test to ignore unrecognizable terms.
339
Note that in this mode, Common Test is not able to check the specification
340
for errors as efficiently as if the scanner runs in default mode.
341
If <c>ct:run_test/1</c> is used for starting the tests, the relaxed scanner
342
mode is enabled by means of the tuple: <c>{allow_user_terms,true}</c></p>
346
<title>Log files</title>
348
<p>As the execution of the test suites go on, events are logged in
349
four different ways:</p>
352
<item>Text to the operator's console.</item>
353
<item>Suite related information is sent to the major log file.</item>
354
<item>Case related information is sent to the minor log file.</item>
355
<item>The HTML overview log file gets updated with test results.</item>
356
<item>A link to all runs executed from a certain directory is written in
357
the log named "all_runs.html" and direct links to all tests (the
358
latest results) are written to the top level "index.html".</item>
361
<p>Typically the operator, who may run hundreds or thousands of
362
test cases, doesn't want to fill the screen with details
363
about/from the specific test cases. By default, the operator will
367
<item>A confirmation that the test has started and information about how
368
many test cases will be executed totally.</item>
369
<item>A small note about each failed test case.</item>
370
<item>A summary of all the run test cases.</item>
371
<item>A confirmation that the test run is complete.</item>
372
<item>Some special information like error reports and progress
373
reports, printouts written with erlang:display/1 or io:format/3
374
specifically addressed to somewhere other than
375
<c>standard_io</c>.</item>
378
<p>This is enough for the operator to know, and if he wants to dig
379
in deeper into a specific test case result, he can do so by
380
following the links in the HTML presentation to take a look in the
381
major or minor log files. The "all_runs.html" page is a practical
382
starting point usually. It's located in <c>logdir</c> and contains
383
a link to each test run including a quick overview (date and time,
384
node name, number of tests, test names and test result totals).</p>
386
<p>An "index.html" page is written for each test run (i.e. stored in
387
the "ct_run" directory tagged with node name, date and time). This
388
file gives a short overview of all individual tests performed in the
389
same test run. The test names follow this convention:</p>
391
<item><em>TopLevelDir.TestDir</em> (all suites in TestDir executed)</item>
392
<item><em>TopLevelDir.TestDir:suites</em> (specific suites were executed)</item>
393
<item><em>TopLevelDir.TestDir.Suite</em> (all cases in Suite executed)</item>
394
<item><em>TopLevelDir.TestDir.Suite:cases</em> (specific test cases were executed)</item>
395
<item><em>TopLevelDir.TestDir.Suite.Case</em> (only Case was executed)</item>
398
<p>On the test run index page there is a link to the Common Test
399
Framework log file in which information about imported
400
configuration data and general test progress is written. This
401
log file is useful to get snapshot information about the test
402
run during execution. It can also be very helpful when
403
analyzing test results or debugging test suites.</p>
405
<p>On the test run index page it is noted if a test has missing
406
suites (i.e. suites that Common Test has failed to
407
compile). Names of the missing suites can be found in the
408
Common Test Framework log file.</p>
410
<p>A detailed report of the test run is stored in the major
411
logfile (textual log file). This includes test suite and test
412
case names, execution time, the exact reason for failure
413
etc. There is an HTML log file that corresponds to this textual file.
414
The HTML file is a summary which gives a better overview of the
415
test run. It also has links to each individual test case log file
416
for quick viewing with an HTML browser.</p>
418
<p>The minor log file contain full details of every single test
419
case, each one in a separate file. This way the files should
420
be easy to compare with previous test runs, even if the set of
421
test cases change.</p>
423
<p>Which information goes where is user configurable via the
424
test server controller. Three threshold values determine what
425
comes out on screen, and in the major or minor log files. See
426
the OTP Test Server manual for information. The contents that
427
goes to the HTML log file is fixed however and cannot be altered.</p>
429
<p>The log files are written continously during a test run and links are
430
always created initially when a test starts. This makes it possible
431
to follow test progress simply by refreshing pages in the HTML browser.
432
Statistics totals are not presented until a test is complete however.</p>
437
<marker id="html_stylesheet"></marker>
438
<title>HTML Style Sheets</title>
439
<p>Common Test includes the <em>optional</em> feature to use
440
HTML style sheets (CSS) for customizing user printouts. The
441
functions in <c>ct</c> that print to a test case HTML log
442
file (<c>log/3</c> and <c>pal/3</c>) accept <c>Category</c>
443
as first argument. With this argument it's possible to
444
specify a category that can be mapped to a selector in a CSS
445
definition. This is useful especially for coloring text
446
differently depending on the type of (or reason for) the
447
printout. Say you want one color for test system
448
configuration information, a different one for test system
449
state information and finally one for errors detected by the
450
test case functions. The corresponding style sheet may
455
div.ct_internal { background:lightgrey; color:black }
456
div.default { background:lightgreen; color:black }
457
div.sys_config { background:blue; color:white }
458
div.sys_state { background:yellow; color:black }
459
div.error { background:red; color:white }
463
<p>To install the CSS file (Common Test inlines the definition in the
464
HTML code), the name may be provided when executing <c>run_test</c>.
468
$ run_test -dir $TEST/prog -stylesheet $TEST/styles/test_categories.css
471
<p>Categories in a CSS file installed with the <c>-stylesheet</c> flag
472
are on a global test level in the sense that they can be used in any
473
suite which is part of the test run.</p>
475
<p>It is also possible to install style sheets on a per suite and
476
per test case basis. Example:</p>
481
suite() -> [..., {stylesheet,"suite_categories.css"}, ...].
485
ct:log(sys_config, "Test node version: ~p", [VersionInfo]),
487
ct:log(sys_state, "Connections: ~p", [ConnectionInfo]),
489
ct:pal(error, "Error ~p detected! Info: ~p", [SomeFault,ErrorInfo]),
493
<p>If the style sheet is installed as in this example, the categories are
494
private to the suite in question. They can be used by all test cases in the
495
suite, but can not be used by other suites. A suite private style sheet,
496
if specified, will be used in favour of a global style sheet (one specified
497
with the <c>-stylesheet</c> flag). A stylesheet tuple (as returned by <c>suite/0</c>
498
above) can also be returned from a test case info function. In this case the
499
categories specified in the style sheet can only be used in that particular
500
test case. A test case private style sheet is used in favour of a suite or
501
global level style sheet.
504
<p>In a tuple <c>{stylesheet,CSSFile}</c>, if <c>CSSFile</c> is specified
505
with a path, e.g. <c>"$TEST/styles/categories.css"</c>, this full
506
name will be used to locate the file. If only the file name is specified
507
however, e.g. "categories.css", then the CSS file is assumed to be located
508
in the data directory, <c>data_dir</c>, of the suite. The latter usage is
509
recommended since it is portable compared to hard coding path names in the
512
<p>The <c>Category</c> argument in the example above may have the
513
value (atom) <c>sys_config</c> (white on blue), <c>sys_state</c>
514
(black on yellow) or <c>error</c> (white on red).</p>
516
<p>If the <c>Category</c> argument is not specified, Common Test will
517
use the CSS selector <c>div.default</c> for the
518
printout. For this reason a user supplied style sheet must
519
include this selector. Also the selector
520
<c>div.ct_internal</c> must be included. Hence a minimal
521
user style sheet should look like this (which is also the
522
default style sheet Common Test uses if no user CSS file is
526
div.ct_internal { background:lightgrey; color:black }
527
div.default { background:lightgreen; color:black }
533
<marker id="repeating_tests"></marker>
534
<title>Repeating tests</title>
535
<p>You can order Common Test to repeat the tests you specify. You can choose
536
to repeat tests a certain number of times, repeat tests for a specific period of time,
537
or repeat tests until a particular stop time is reached. If repetition is controlled by
538
means of time, it is also possible to specify what action Common Test should
539
take upon timeout. Either Common Test performs all tests in the current run before stopping,
540
or it stops as soon as the current test job is finished. Repetition can be activated by
541
means of <c>run_test</c> start flags, or tuples in the <c>ct:run:test/1</c>
542
option list argument. The flags (options in parenthesis) are:</p>
544
<item><c>-repeat N ({repeat,N})</c>, where <c>N</c> is a positive integer.</item>
545
<item><c>-duration DurTime ({duration,DurTime})</c>, where <c>DurTime</c> is the duration, see below.</item>
546
<item><c>-until StopTime ({until,StopTime})</c>, where <c>StopTime</c> is finish time, see below.</item>
547
<item><c>-force_stop ({force_stop,true})</c></item>
549
<p>The duration time, <c>DurTime</c>, is specified as <c>HHMMSS</c>. Example:
550
<c>-duration 012030</c> or <c>{duration,"012030"}</c>, means the tests will
551
be executed and (if time allows) repeated, until timeout occurs after 1 h, 20 min
553
<c>StopTime</c> can be specified as <c>HHMMSS</c> and is then interpreted as a time today
554
(or possibly tomorrow). <c>StopTime</c> can also be specified as <c>YYMoMoDDHHMMSS</c>.
555
Example: <c>-until 071001120000</c> or <c>{until,"071001120000"}</c>, which means the tests
556
will be executed and (if time allows) repeated, until 12 o'clock on the 1st of Oct 2007.</p>
558
<p>When timeout occurs, Common Test will never abort the test run immediately, since
559
this might leave the system under test in an undefined, and possibly bad, state.
560
Instead Common Test will finish the current test job, or the complete test
561
run, before stopping. The latter is the default behaviour. The <c>force_stop</c>
562
flag/option tells Common Test to stop as soon as the current test job is finished.
563
Note that since Common Test always finishes off the current test job or test session,
564
the time specified with <c>duration</c> or <c>until</c> is never definitive!</p>
566
<p>Log files from every single repeated test run is saved in normal Common Test fashion (see above).
567
Common Test may later support an optional feature to only store the last (and possibly
568
the first) set of logs of repeated test runs, but for now the user must be careful not
569
to run out of disk space if tests are repeated during long periods of time.</p>
571
<p>Note that for each test run that is part of a repeated session, information about the
572
particular test run is printed in the Common Test Framework Log. There you can read
573
the repetition number, remaining time, etc.</p>
577
$ run_test -dir $TEST_ROOT/to1 $TEST_ROOT/to2 -duration 001000 -force_stop</pre>
578
<p>Here the suites in test directory to1, followed by the suites in to2, will be executed
579
in one test run. A timeout event will occur after 10 minutes. As long as there is time
580
left, Common Test will repeat the test run (i.e. starting over with the to1 test).
581
When the timeout occurs, Common Test will stop as soon as the current job is finished
582
(because of the <c>force_stop</c> flag). As a result, the specified test run might be
583
aborted after the to1 test and before the to2 test.</p>
588
Fri Sep 28 15:00:00 MEST 2007
590
$ run_test -dir $TEST_ROOT/to1 $TEST_ROOT/to2 -until 160000</pre>
591
<p>Here the same test run as in the example above will be executed (and possibly repeated).
592
In this example, however, the timeout will occur after 1 hour and when that happens,
593
Common Test will finish the entire test run before stopping (i.e. the to1 and to2 test
594
will always both be executed in the same test run).</p>
598
$ run_test -dir $TEST_ROOT/to1 $TEST_ROOT/to2 -repeat 5</pre>
599
<p>Here the test run, including both the to1 and the to2 test, will be repeated 5 times.</p>
603
<marker id="silent_connections"></marker>
604
<title>Silent Connections</title>
605
<p>The protocol handling processes in Common Test, implemented by ct_telnet, ct_ftp etc,
606
do verbose printing to the test case logs. This can be switched off by means
607
of the <c>-silent_connections</c> flag:</p>
610
run_test -silent_connections [conn_types]
613
<p>where <c>conn_types</c> specifies <c>telnet, ftp, rpc</c> and/or <c>snmp</c>.</p>
618
run_test ... -silent_connections telnet ftp</pre>
619
<p>switches off logging for telnet and ftp connections.</p>
622
run_test ... -silent_connections</pre>
623
<p>switches off logging for all connection types.</p>
626
<p>Basic and important information such as opening and closing a connection,
627
fatal communication error and reconnection attempts will always be printed even
628
if logging has been suppressed for the connection type in question. However, operations
629
such as sending and receiving data may be performed silently.</p>
631
<p>It is possible to also specify <c>silent_connections</c> in a test suite. This is
632
accomplished by returning a tuple, <c>{silent_connections,ConnTypes}</c>, in the
633
<c>suite/0</c> or test case info list. If <c>ConnTypes</c> is a list of atoms
634
(<c>telnet, ftp, rpc</c> and/or <c>snmp</c>), output for any corresponding connections
635
will be suppressed. Full logging is per default enabled for any connection of type not
636
specified in <c>ConnTypes</c>. Hence, if <c>ConnTypes</c> is the empty list, logging
637
is enabled for all connections.</p>
639
<p>The <c>silent_connections</c> setting returned from a test case info function overrides,
640
for the test case in question, any setting made with <c>suite/0</c> (which is the setting
641
used for all cases in the suite). Example:</p>
647
suite() -> [..., {silent_connections,[telnet,ftp]}, ...].
650
[{silent_connections,[ftp]}].
657
<p>In this example, <c>suite/0</c> tells Common Test to suppress
658
printouts from telnet and ftp connections. This is valid for
659
all test cases. However, <c>my_testcase1/0</c> specifies that
660
for this test case, only ftp should be silent. The result is
661
that <c>my_testcase1</c> will get telnet info (if any) printed
662
in the log, but not ftp info. <c>my_testcase2</c> will get no
663
info from either connection printed.</p>
665
<p>The <c>-silent_connections</c> tag (or
666
<c>silent_connections</c> tagged tuple in the call to
667
<c>ct:run_test/1</c>) overrides any settings in the test
670
<p>Note that in the current Common Test version, the
671
<c>silent_connections</c> feature only works for telnet
672
connections. Support for other connection types will be added
673
in future Common Test versions.</p>
added
removed
lib/common_test/doc/src/run_test_chapter.xml
