1
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
5
>Hints On Writing A Test Case</TITLE
8
CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
12
HREF="book1.html"><LINK
14
TITLE="Extending DejaGnu"
15
HREF="c1099.html"><LINK
17
TITLE="Adding A Test Case To A Testsuite."
18
HREF="x1493.html"><LINK
20
TITLE="Special variables used by test cases."
21
HREF="x1551.html"></HEAD
32
SUMMARY="Header navigation table"
41
>DejaGnu: The GNU Testing Framework</TH
51
><<< Previous</A
57
>Extending DejaGnu</TD
65
>Next >>></A
79
>Hints On Writing A Test Case</H1
81
>It is safest to write patterns that match all the output
82
generated by the tested program; this is called closure.
83
If a pattern does not match the entire output, any output that
84
remains will be examined by the next <B
88
command. In this situation, the precise boundary that determines
92
> command sees what is very
93
sensitive to timing between the Expect task and the task running
94
the tested tool. As a result, the test may sometimes appear to
95
work, but is likely to have unpredictable results. (This problem
96
is particularly likely for interactive tools, but can also
97
affect batch tools---especially for tests that take a long time
98
to finish.) The best way to ensure closure is to use the
106
command to write the pattern as a full regular expressions; then
107
you can match the end of output using a <I
111
It is also a good idea to write patterns that match all
112
available output by using <I
116
text of interest; this will also match any intervening blank
117
lines. Sometimes an alternative is to match end of line using
125
usually too dependent on terminal settings.</P
127
>Always escape punctuation, such as <I
134
>, in your patterns; for example, write
138
>. If you forget to escape punctuation,
139
you will usually see an error message like <TABLE
146
CLASS="PROGRAMLISTING"
148
characters after close-quote.</PRE
154
>If you have trouble understanding why a pattern does not
155
match the program output, try using the <TT
162
>, and examine the debug log
165
>Be careful not to neglect output generated by setup rather
166
than by the interesting parts of a test case. For example,
167
while testing GDB, I issue a send <I
171
> command. The purpose is simply to make sure GDB
172
never calls a paging program. The <I
176
> command in GDB does not generate any
177
output; but running any command makes GDB issue a new
181
> prompt. If there were no
185
> command to match this prompt, the
189
> begins the text seen by the
193
> command---which might make that
194
pattern fail to match.</P
196
>To preserve basic sanity, I also recommended that no test
197
ever pass if there was any kind of problem in the test case. To
198
take an extreme case, tests that pass even when the tool will
199
not spawn are misleading. Ideally, a test in this sort of
200
situation should not fail either. Instead, print an error
201
message by calling one of the DejaGnu procedures
215
SUMMARY="Footer navigation table"
228
><<< Previous</A
246
>Next >>></A
254
>Adding A Test Case To A Testsuite.</TD
268
>Special variables used by test cases.</TD
b'\\ No newline at end of file'
added
removed
doc/html/x1522.html
