<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML
><HEAD
><TITLE
>Test fixtures
</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
REL="HOME"
TITLE="Check Tutorial"
HREF="index.html"><LINK
REL="UP"
TITLE="Advanced Features
"
HREF="c163.html"><LINK
REL="PREVIOUS"
TITLE="No fork mode
"
HREF="x172.html"><LINK
REL="NEXT"
TITLE="Multiple suites run through the same SRunner
"
HREF="x214.html"></HEAD
><BODY
CLASS="SECTION"
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"
>Check Tutorial</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="x172.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
>Chapter 4. Advanced Features</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="x214.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECTION"
><H1
CLASS="SECTION"
><A
NAME="AEN183"
>4.3. Test fixtures</A
></H1
><P
>We may want multiple tests that all use the same Money. In such cases, rather than setting up and tearing down objects for each unit test, it may be convenient to add some setup that is constant across all the tests in a test case. In the extreme programming approach to unit tests, such setup is called a test fixture.
</P
><P
>A fixture is created by defining a setup and/or a teardown function, and associating it with a test case. There are two kinds of test fixtures in Check: checked and unchecked fixtures. These are defined as follows:
</P
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>Checked fixtures</DT
><DD
><P
>are run inside the address space created by the fork to create the unit test. Before each unit test in a test case, the setup function is run, if defined. After each unit test, the teardown function is run, if defined. Because they run inside the forked address space, if checked fixtures signal or otherwise fail, they will be caught and reported by the SRunner.
</P
></DD
><DT
>Unchecked fixtures</DT
><DD
><P
>are run in the same address space as the test program. Therefore they may not signal or exit, but may use the fail functions. The unchecked setup, if defined, is run before the test case is started. The unchecked teardown, if defined, is run after the test case is done.
</P
></DD
></DL
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="AEN196"
>4.3.1. Test fixture examples</A
></H2
><P
>We create a test fixture in Check as follows:
</P
><P
></P
><OL
TYPE="1"
><LI
><P
>Define the global variables, and functions to setup and teardown the globals. The functions both take void and return void
</P
><PRE
CLASS="PROGRAMLISTING"
>Money *five_dollars;
void setup(void) {
five_dollars = money_create(5, "USD");
}
void teardown(void)
{
money_free(five_dollars);
}</PRE
></LI
><LI
><P
>Add the setup and teardown functions to the test case with “tcase_add_checked_fixture” (this belongs in the suite setup function “money_suite”:
</P
><PRE
CLASS="PROGRAMLISTING"
>tcase_add_checked_fixture(tc_core, setup, teardown);</PRE
></LI
><LI
><P
>We can now rewrite the first test we wrote as follows:
</P
><PRE
CLASS="PROGRAMLISTING"
>START_TEST (test_create)
{
fail_unless(money_amount(five_dollars) == 5,
"Amount not set correctly on creation");
fail_unless (strcmp(money_currency(five_dollars), "USD") == 0,
"Currency not set correctly on creation");
}
END_TEST</PRE
></LI
></OL
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="AEN209"
>4.3.2. Checked vs Unchecked fixtures</A
></H2
><P
>Because checked fixtures run once per unit test, they should not be used for expensive setup. Because unchecked fixtures may take down the entire test program, they should only be used if they are known to be safe.
</P
><P
>Additionally, checked and uncheck fixtures may behave differently in CK_NOFORK mode. Because the fork creates a separate address space, in CK_FORK mode unit tests may abuse the objects created in an unchecked fixture with impunity, without affecting other unit tests in the same test case. However, in CK_NOFORK mode, all tests live in the same address space, and side effects in one test will affect the unchecked fixture for other tests. A checked fixture, however, will generally not be affected by unit test side effects, since the setup is run before each unit test. (There is an exception for side effects to the total environment in which the test program lives: e.g., if the setup function initializes a file that a unit test then changes, the combination of the teardown function and setup fuction must be able to restore the environment for the next unit test).
</P
><P
>If the setup function in a fixture fails, in either checked or unchecked fixtures, the unit tests for the test case, and the teardown function for the fixture will not be run. A fixture error will be created and reported to the SRunner.
</P
></DIV
></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="x172.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="x214.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>No fork mode</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="c163.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Multiple suites run through the same SRunner</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
