1
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
5
>The files DejaGnu produces.</TITLE
8
CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
12
HREF="book1.html"><LINK
15
HREF="c401.html"><LINK
18
HREF="x428.html"><LINK
20
TITLE="Customizing DejaGnu"
21
HREF="c848.html"></HEAD
32
SUMMARY="Header navigation table"
41
>DejaGnu: The GNU Testing Framework</TH
51
><<< Previous</A
65
>Next >>></A
79
>The files DejaGnu produces.</H1
81
>DejaGnu always writes two kinds of output files: summary
82
logs and detailed logs. The contents of both of these are
83
determined by your tests.</P
85
>For troubleshooting, a third kind of output file is useful:
89
> to request an output file showing
104
>DejaGnu always produces a summary output file
108
>. This summary shows the names of
109
all test files run; for each test file, one line of output from
113
> command (showing status
132
trailing summary statistics that count passing and failing tests
133
(expected and unexpected); and the full pathname and version
134
number of the tool tested. (All possible outcomes, and all
135
errors, are always reflected in the summary output file,
136
regardless of whether or not you specify
142
>If any of your tests use the procedures
153
>, the summary output also
154
tabulates the corresponding outcomes.</P
156
>For example, after <B
160
>, look for a summary log in
164
>. Normally, DejaGnu writes this
165
file in your current working directory; use the
169
> option to select a different
178
>Example 1. Here is a short sample summary log</B
188
> Test Run By rob on Mon May 25 21:40:57 PDT 1992
190
Running ./gdb.t00/echo.exp ...
192
Running ./gdb.all/help.exp ...
193
PASS: help add-symbol-file
195
PASS: help breakpoint "bre" abbreviation
196
FAIL: help run "r" abbreviation
197
Running ./gdb.t10/crossload.exp ...
198
PASS: m68k-elf (elf-big) explicit format; loaded
199
XFAIL: mips-ecoff (ecoff-bigmips) "ptype v_signed_char" signed C types
201
# of expected passes 5
202
# of expected failures 1
203
# of unexpected failures 1
204
/usr/latest/bin/gdb version 4.6.5 -q
220
>DejaGnu also saves a detailed log file
224
>, showing any output generated by
225
tests as well as the summary output. For example, after
228
>runtest --tool binutils</B
229
>, look for a detailed
234
writes this file in your current working directory; use the
238
> option to select a different
247
>Example 2. Here is a brief example showing a detailed log for
261
> Test Run By rob on Mon May 25 21:40:43 PDT 1992
265
--- Running ./g++.other/t01-1.exp ---
268
--- Running ./g++.other/t01-2.exp ---
270
p0000646.C: In function `int warn_return_1 ()':
271
p0000646.C:109: warning: control reaches end of non-void function
272
p0000646.C: In function `int warn_return_arg (int)':
273
p0000646.C:117: warning: control reaches end of non-void function
274
p0000646.C: In function `int warn_return_sum (int, int)':
275
p0000646.C:125: warning: control reaches end of non-void function
276
p0000646.C: In function `struct foo warn_return_foo ()':
277
p0000646.C:132: warning: control reaches end of non-void function
279
--- Running ./g++.other/t01-4.exp ---
281
900403_04.C:8: zero width for bit-field `foo'
282
--- Running ./g++.other/t01-3.exp ---
283
FAIL: segment violation
284
900519_12.C:9: parse error before `;'
285
900519_12.C:12: Segmentation violation
286
/usr/latest/bin/gcc: Internal compiler error: program cc1plus got fatal signal
290
# of expected passes 1
291
# of expected failures 3
292
/usr/latest/bin/g++ version cygnus-2.0.1
311
> option, you can request
312
a log file showing the output from
316
> itself, running in debugging
324
>) shows each pattern
328
> considers in analyzing test
331
>This file reflects each <B
335
showing the string sent as input to the tool under test; and
339
> command, showing each
340
pattern it compares with the tool output.</P
348
>Example 3. The log messages begin with a message of the form</B
358
> expect: does {<SPAN
376
>For every unsuccessful match,
384
> after this message; if other patterns
385
are specified for the same <SPAN
389
command, they are reflected also, but without the first part of
392
>expect... match pattern</I
399
log for the successful match ends with <I
403
followed by a record of the <SPAN
407
variables set to describe a successful match.</P
415
>Example 4. Here is an excerpt from the debugging log for a
429
> send: sent {break gdbme.c:34\n} to spawn id 6
430
expect: does {} (spawn_id 6) match pattern {Breakpoint.*at.* file
431
gdbme.c, line 34.*\(gdb\) $}? no
433
expect: does {} (spawn_id 0) match pattern {return} ? no
442
Breakpoint 8 at 0x23d8: file gdbme.c, line 34.
443
(gdb) expect: does {break gdbme.c:34\r\nBreakpoint 8 at 0x23d8:
444
file gdbme.c, line 34.\r\n(gdb) } (spawn_id 6) match pattern
445
{Breakpoint.*at.* file gdbme.c, line 34.*\(gdb\) $}? yes
446
expect: set expect_out(0,start) {18}
447
expect: set expect_out(0,end) {71}
448
expect: set expect_out(0,string) {Breakpoint 8 at 0x23d8: file
449
gdbme.c, line 34.\r\n(gdb) }
450
epect: set expect_out(spawn_id) {6}
451
expect: set expect_out(buffer) {break gdbme.c:34\r\nBreakpoint 8
452
at 0x23d8: file gdbme.c, line 34.\r\n(gdb) }
453
PASS: 70 0 breakpoint line number in file
460
>This example exhibits three properties of
468
> that might be surprising at
474
STYLE="list-style-type: disc"
476
>Empty output for the first attempted match. The
477
first set of attempted matches shown ran against the output
486
attempting to match the patterns supplied immediately; often,
487
the first pass is against incomplete output (or completely
488
before all output, as in this case).</P
491
STYLE="list-style-type: disc"
493
>Interspersed tool output. The beginning of
494
the log entry for the second attempted match may be hard to
495
spot: this is because the prompt <I
499
appears on the same line, just before the
503
> that marks the beginning of the
507
STYLE="list-style-type: disc"
509
>Fail-safe patterns. Many of the patterns
510
tested are fail-safe patterns provided by
514
> testing utilities, to reduce
515
possible indeterminacy. It is useful to anticipate potential
516
variations caused by extreme system conditions
520
> might issue the message
523
>virtual memory exhausted</I
525
circumstances), or by changes in the tested program
528
>Undefined command</I
530
outcome if the name of a tested command changes).</P
536
particularly interesting fail-safe to notice; it checks for an
540
> prompt. This may happen,
541
for example, if the tested tool can filter output through a
544
>These fail-safe patterns (like the debugging log itself)
545
are primarily useful while developing test scripts. Use the
549
> procedure to make the actions for
550
fail-safe patterns produce messages starting with
554
> on standard output, and in the
555
detailed log file.</P
565
SUMMARY="Footer navigation table"
578
><<< Previous</A
596
>Next >>></A
618
>Customizing DejaGnu</TD
b'\\ No newline at end of file'
added
removed
doc/html/x755.html
