aboutsummaryrefslogtreecommitdiffstats
path: root/lib/test_server/doc
diff options
context:
space:
mode:
Diffstat (limited to 'lib/test_server/doc')
-rw-r--r--lib/test_server/doc/src/example_chapter.xml28
-rw-r--r--lib/test_server/doc/src/notes.xml22
-rw-r--r--lib/test_server/doc/src/test_server.xml66
3 files changed, 50 insertions, 66 deletions
diff --git a/lib/test_server/doc/src/example_chapter.xml b/lib/test_server/doc/src/example_chapter.xml
index 0ebc85da09..6bc0cfaebe 100644
--- a/lib/test_server/doc/src/example_chapter.xml
+++ b/lib/test_server/doc/src/example_chapter.xml
@@ -47,7 +47,7 @@
-define(default_timeout, ?t:minutes(1)).
init_per_testcase(_Case, Config) ->
- ?line Dog=?t:timetrap(?default_timeout),
+ Dog=?t:timetrap(?default_timeout),
[{watchdog, Dog}|Config].
end_per_testcase(_Case, Config) ->
Dog=?config(watchdog, Config),
@@ -72,8 +72,8 @@ not_started_func1(suite) ->
not_started_func1(doc) ->
["Testing function 1 when application is not started"].
not_started_func1(Config) when list(Config) ->
- ?line {error, not_started} = myapp:func1(dummy_ref,1),
- ?line {error, not_started} = myapp:func1(dummy_ref,2),
+ {error, not_started} = myapp:func1(dummy_ref,1),
+ {error, not_started} = myapp:func1(dummy_ref,2),
ok.
not_started_func2(suite) ->
@@ -81,8 +81,8 @@ not_started_func2(suite) ->
not_started_func2(doc) ->
["Testing function 2 when application is not started"].
not_started_func2(Config) when list(Config) ->
- ?line {error, not_started} = myapp:func2(dummy_ref,1),
- ?line {error, not_started} = myapp:func2(dummy_ref,2),
+ {error, not_started} = myapp:func2(dummy_ref,1),
+ {error, not_started} = myapp:func2(dummy_ref,2),
ok.
@@ -90,7 +90,7 @@ not_started_func2(Config) when list(Config) ->
start(doc) ->
["Testing start of my application."];
start(Config) when list(Config) ->
- ?line Ref = myapp:start(),
+ Ref = myapp:start(),
case erlang:whereis(my_main_process) of
Pid when pid(Pid) ->
[{myapp_ref,Ref}|Config];
@@ -105,9 +105,9 @@ func1(suite) ->
func1(doc) ->
["Test that func1 returns ok when argument is 1 and error if argument is 2"];
func1(Config) when list(Config) ->
- ?line Ref = ?config(myapp_ref,Config),
- ?line ok = myapp:func1(Ref,1),
- ?line error = myapp:func1(Ref,2),
+ Ref = ?config(myapp_ref,Config),
+ ok = myapp:func1(Ref,1),
+ error = myapp:func1(Ref,2),
ok.
func2(suite) ->
@@ -115,17 +115,17 @@ func2(suite) ->
func2(doc) ->
["Test that func1 returns ok when argument is 3 and error if argument is 4"];
func2(Config) when list(Config) ->
- ?line Ref = ?config(myapp_ref,Config),
- ?line ok = myapp:func2(Ref,3),
- ?line error = myapp:func2(Ref,4),
+ Ref = ?config(myapp_ref,Config),
+ ok = myapp:func2(Ref,3),
+ error = myapp:func2(Ref,4),
ok.
%% No specification clause needed for a cleanup function in a conf case!!!
stop(doc) ->
["Testing termination of my application"];
stop(Config) when list(Config) ->
- ?line Ref = ?config(myapp_ref,Config),
- ?line ok = myapp:stop(Ref),
+ Ref = ?config(myapp_ref,Config),
+ ok = myapp:stop(Ref),
case erlang:whereis(my_main_process) of
undefined ->
lists:keydelete(myapp_ref,1,Config);
diff --git a/lib/test_server/doc/src/notes.xml b/lib/test_server/doc/src/notes.xml
index f21c32a304..e996d2b4a3 100644
--- a/lib/test_server/doc/src/notes.xml
+++ b/lib/test_server/doc/src/notes.xml
@@ -32,6 +32,28 @@
<file>notes.xml</file>
</header>
+<section><title>Test_Server 3.8.1</title>
+
+ <section><title>Fixed Bugs and Malfunctions</title>
+ <list>
+ <item>
+ <p>
+ If the last expression in a test case causes a timetrap
+ timeout, the stack trace is ignored and not printed to
+ the test case log file. This happens because the
+ {Suite,TestCase,Line} info is not available in the stack
+ trace in this scenario, due to tail call elimination.
+ Common Test has been modified to handle this situation by
+ inserting a {Suite,TestCase,last_expr} tuple in the
+ correct place and printing the stack trace as expected.</p>
+ <p>
+ Own Id: OTP-12697 Aux Id: seq12848 </p>
+ </item>
+ </list>
+ </section>
+
+</section>
+
<section><title>Test_Server 3.8</title>
<section><title>Fixed Bugs and Malfunctions</title>
diff --git a/lib/test_server/doc/src/test_server.xml b/lib/test_server/doc/src/test_server.xml
index ed5569e1fe..b98e434c03 100644
--- a/lib/test_server/doc/src/test_server.xml
+++ b/lib/test_server/doc/src/test_server.xml
@@ -811,46 +811,12 @@ Only valid for peer nodes. Note that slave nodes always
</func>
</funcs>
- <section>
- <title>TEST SUITE LINE NUMBERS</title>
- <p>If a test case fails, the test server can report the exact line
- number at which it failed. There are two ways of doing this,
- either by using the <c>line</c> macro or by using the
- <c>test_server_line</c> parse transform.
- </p>
- <p>The <c>line</c> macro is described under TEST SUITE SUPPORT
- MACROS below. The <c>line</c> macro will only report the last line
- executed when a test case failed.
- </p>
- <p>The <c>test_server_line</c> parse transform is activated by
- including the headerfile <c>test_server_line.hrl</c> in the test
- suite. When doing this, it is important that the
- <c>test_server_line</c> module is in the code path of the erlang
- node compiling the test suite. The parse transform will report a
- history of a maximum of 10 lines when a test case
- fails. Consecutive lines in the same function are not shown.
- </p>
- <p>The attribute <c>-no_lines(FuncList).</c> can be used in the
- test suite to exclude specific functions from the parse
- transform. This is necessary e.g. for functions that are executed
- on old (i.e. &lt;R10B) OTP releases. <c>FuncList = [{Func,Arity}]</c>.
- </p>
- <p>If both the <c>line</c> macro and the parse transform is used in
- the same module, the parse transform will overrule the macro.
- </p>
- </section>
<section>
<title>TEST SUITE SUPPORT MACROS</title>
<p>There are some macros defined in the <c>test_server.hrl</c>
that are quite useful for test suite programmers:
</p>
- <p>The <em>line</em> macro, is quite
- essential when writing test cases. It tells the test server
- exactly what line of code that is being executed, so that it can
- report this line back if the test case fails. Use this macro at
- the beginning of every test case line of code.
- </p>
<p>The <em>config</em> macro, is used to
retrieve information from the <c>Config</c> variable sent to all
test cases. It is used with two arguments, where the first is the
@@ -867,24 +833,20 @@ Only valid for peer nodes. Note that slave nodes always
<item>Whatever added by conf test cases or
<c>init_per_testcase/2</c></item>
</list>
- <p>Examples of the <c>line</c> and <c>config</c> macros can be
- seen in the Examples chapter in the user's guide.
- </p>
- <p>If the <c>line_trace</c> macro is defined, you will get a
- timestamp (<c>erlang:now()</c>) in your minor log for each
- <c>line</c> macro in your suite. This way you can at any time see
- which line is currently being executed, and when the line was
- called.
- </p>
- <p>The <c>line_trace</c> macro can also be used together with the
- <c>test_server_line</c> parse transform described above. A
- timestamp will then be written for each line in the suite, except
- for functions stated in the <c>-no_lines</c> attribute.
- </p>
- <p>The <c>line_trace</c> macro can e.g. be defined as a compile
- option, like this:
- <br></br>
-<c>erlc -W -Dline_trace my_SUITE.erl</c></p>
+ <p>Examples of the <c>config</c> macro can be seen in the Examples chapter
+ in the user's guide.</p>
+ <p>The <em>line</em> and <em>line_trace</em> macros are deprecated, see
+ below.</p>
+ </section>
+
+ <section>
+ <title>TEST SUITE LINE NUMBERS</title>
+ <p>In the past, ERTS did not produce line numbers when generating
+ stacktraces, test_server was thus unable to provide them when reporting
+ test failures. It had instead two different mecanisms to do it: either by
+ using the <c>line</c> macro or by using the <c>test_server_line</c> parse
+ transform. Both are deprecated and should not be used in new tests
+ anymore.</p>
</section>
</erlref>