blob: e1fd843f92e87cd05fde1536eb0490e847e4146d [file] [log] [blame]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<HTML
><HEAD
><TITLE
>Hints On Writing A Test Case</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
"><LINK
REL="HOME"
TITLE="DejaGnu"
HREF="book1.html"><LINK
REL="UP"
TITLE="Extending DejaGnu"
HREF="c1099.html"><LINK
REL="PREVIOUS"
TITLE="Adding A Test Case To A Testsuite."
HREF="x1493.html"><LINK
REL="NEXT"
TITLE="Special variables used by test cases."
HREF="x1551.html"></HEAD
><BODY
CLASS="SECT1"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>DejaGnu: The GNU Testing Framework</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="x1493.html"
ACCESSKEY="P"
>&#60;&#60;&#60; Previous</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
>Extending DejaGnu</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="x1551.html"
ACCESSKEY="N"
>Next &#62;&#62;&#62;</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="HINTS"
></A
>Hints On Writing A Test Case</H1
><P
>It is safest to write patterns that match all the output
generated by the tested program; this is called closure.
If a pattern does not match the entire output, any output that
remains will be examined by the next <B
CLASS="COMMAND"
>expect</B
>
command. In this situation, the precise boundary that determines
which <B
CLASS="COMMAND"
>expect</B
> command sees what is very
sensitive to timing between the Expect task and the task running
the tested tool. As a result, the test may sometimes appear to
work, but is likely to have unpredictable results. (This problem
is particularly likely for interactive tools, but can also
affect batch tools---especially for tests that take a long time
to finish.) The best way to ensure closure is to use the
<TT
CLASS="OPTION"
>-re</TT
> option for the <B
CLASS="COMMAND"
>expect</B
>
command to write the pattern as a full regular expressions; then
you can match the end of output using a <I
CLASS="EMPHASIS"
>$</I
>.
It is also a good idea to write patterns that match all
available output by using <I
CLASS="EMPHASIS"
>.*\</I
> after the
text of interest; this will also match any intervening blank
lines. Sometimes an alternative is to match end of line using
<I
CLASS="EMPHASIS"
>\r</I
> or <I
CLASS="EMPHASIS"
>\n</I
>, but this is
usually too dependent on terminal settings.</P
><P
>Always escape punctuation, such as <I
CLASS="EMPHASIS"
>(</I
>
or <I
CLASS="EMPHASIS"
>"</I
>, in your patterns; for example, write
<I
CLASS="EMPHASIS"
>\(</I
>. If you forget to escape punctuation,
you will usually see an error message like <TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>extra
characters after close-quote.</PRE
></TD
></TR
></TABLE
></P
><P
>If you have trouble understanding why a pattern does not
match the program output, try using the <TT
CLASS="OPTION"
>--debug</TT
>
option to <B
CLASS="COMMAND"
>runtest</B
>, and examine the debug log
carefully.</P
><P
>Be careful not to neglect output generated by setup rather
than by the interesting parts of a test case. For example,
while testing GDB, I issue a send <I
CLASS="EMPHASIS"
>set height
0\n</I
> command. The purpose is simply to make sure GDB
never calls a paging program. The <I
CLASS="EMPHASIS"
>set
height</I
> command in GDB does not generate any
output; but running any command makes GDB issue a new
<I
CLASS="EMPHASIS"
>(gdb) </I
> prompt. If there were no
<B
CLASS="COMMAND"
>expect</B
> command to match this prompt, the
output <I
CLASS="EMPHASIS"
>(gdb) </I
> begins the text seen by the
next <B
CLASS="COMMAND"
>expect</B
> command---which might make that
pattern fail to match.</P
><P
>To preserve basic sanity, I also recommended that no test
ever pass if there was any kind of problem in the test case. To
take an extreme case, tests that pass even when the tool will
not spawn are misleading. Ideally, a test in this sort of
situation should not fail either. Instead, print an error
message by calling one of the DejaGnu procedures
<B
CLASS="COMMAND"
>error</B
> or <B
CLASS="COMMAND"
>warning</B
>.</P
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="x1493.html"
ACCESSKEY="P"
>&#60;&#60;&#60; Previous</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="book1.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="x1551.html"
ACCESSKEY="N"
>Next &#62;&#62;&#62;</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Adding A Test Case To A Testsuite.</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="c1099.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Special variables used by test cases.</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>