4 >Hints On Writing A Test Case
</TITLE
7 CONTENT=
"Modular DocBook HTML Stylesheet Version 1.44"><LINK
10 HREF=
"book1.html"><LINK
12 TITLE=
"Extending DejaGnu"
13 HREF=
"extending.html"><LINK
15 TITLE=
"Adding A Test Case To A Test Suite."
16 HREF=
"adding.html"><LINK
18 TITLE=
"Special variables used by test cases."
19 HREF=
"tvariables.html"></HEAD
32 >DejaGnu: The GNU Testing Framework
</TH
47 >Chapter
4. Extending DejaGnu
</TD
53 HREF=
"tvariables.html"
67 >Hints On Writing A Test Case
</A
70 >It is safest to write patterns that match all the output
71 generated by the tested program; this is called closure.
72 If a pattern does not match the entire output, any output that
73 remains will be examined by the next
<B
77 command. In this situation, the precise boundary that determines
81 > command sees what is very
82 sensitive to timing between the Expect task and the task running
83 the tested tool. As a result, the test may sometimes appear to
84 work, but is likely to have unpredictable results. (This problem
85 is particularly likely for interactive tools, but can also
86 affect batch tools---especially for tests that take a long time
87 to finish.) The best way to ensure closure is to use the
95 command to write the pattern as a full regular expressions; then
96 you can match the end of output using a
<I
100 It is also a good idea to write patterns that match all
101 available output by using
<I
105 text of interest; this will also match any intervening blank
106 lines. Sometimes an alternative is to match end of line using
114 usually too dependent on terminal settings.
</P
116 >Always escape punctuation, such as
<I
123 >, in your patterns; for example, write
127 >. If you forget to escape punctuation,
128 you will usually see an error message like <TABLE
135 CLASS="PROGRAMLISTING
"
137 characters after close-quote.</PRE
143 >If you have trouble understanding why a pattern does not
144 match the program output, try using the <TT
151 >, and examine the debug log
154 >Be careful not to neglect output generated by setup rather
155 than by the interesting parts of a test case. For example,
156 while testing GDB, I issue a send <I
160 > command. The purpose is simply to make sure GDB
161 never calls a paging program. The <I
165 > command in GDB does not generate any
166 output; but running any command makes GDB issue a new
170 > prompt. If there were no
174 > command to match this prompt, the
178 > begins the text seen by the
182 > command---which might make that
183 pattern fail to match.</P
185 >To preserve basic sanity, I also recommended that no test
186 ever pass if there was any kind of problem in the test case. To
187 take an extreme case, tests that pass even when the tool will
188 not spawn are misleading. Ideally, a test in this sort of
189 situation should not fail either. Instead, print an error
190 message by calling one of the DejaGnu procedures
230 HREF="tvariables.html
"
239 >Adding A Test Case To A Test Suite.</TD
245 HREF="extending.html
"
252 >Special variables used by test cases.</TD