mirror of
https://github.com/boostorg/test.git
synced 2026-02-13 12:52:10 +00:00
113 lines
7.3 KiB
HTML
Executable File
113 lines
7.3 KiB
HTML
Executable File
<html>
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=US-ASCII">
|
|
<title>Test organization … or the house that Jack built</title>
|
|
<link rel="stylesheet" href="../../../style/style.css" type="text/css">
|
|
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
|
|
<link rel="home" href="../../index.html" title="Boost Test Library">
|
|
<link rel="up" href="../user-guide.html" title="Unit Test Framework: User's guide">
|
|
<link rel="prev" href="usage-variants/extern-test-runner-variant.html" title="The external test runner variant of the UTF">
|
|
<link rel="next" href="test-organization/nullary-test-case.html" title="Nullary function based test case">
|
|
<script language="JavaScript1.2" src="../../../js/boost-test.js"></script>
|
|
</head>
|
|
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
|
|
<table width="100%"><tr>
|
|
<td width="10%"><a href="../../index.html"><img alt="Home" width="229" height="61" border="0" src="../../../../../../libs/test/doc/img/boost.test.logo.png"></a></td>
|
|
<td valign="middle" align="left"> > <a href="../../utf.html">The Unit Test Framework</a><a href="../../execution-monitor.html">
|
|
>
|
|
</a><a href="../user-guide.html">User's guide</a><a href="../usage-recommendations.html">
|
|
>
|
|
</a><b>Test organization</b><a href="testing-tools.html">
|
|
>
|
|
</a>
|
|
</td>
|
|
<td><div class="spirit-nav">
|
|
<a href="usage-variants/extern-test-runner-variant.html"><img src="../../../../../../doc/src/images/prev.png" alt="Prev"></a><a href="test-organization/nullary-test-case.html"><img src="../../../../../../doc/src/images/next.png" alt="Next"></a>
|
|
</div></td>
|
|
</tr></table>
|
|
<hr>
|
|
<div class="section">
|
|
<div class="titlepage"><div><div><h4 class="title">
|
|
<a name="utf.user-guide.test-organization"></a>Test organization … or the house that Jack built</h4></div></div></div>
|
|
<p class="first-line-indented">
|
|
If you look at many legacy test modules, big chance is that it's implemented as one big test function that
|
|
consists of a mixture of check and output statements. Is there anything wrong with it? Yes. There are various
|
|
disadvantages in single test function approach:
|
|
</p>
|
|
<div class="itemizedlist"><ul type="square">
|
|
<li class="listitem" style="list-style-type: square">
|
|
One big function tends to become really difficult to manage if the number of checks exceeds a reasonable limit
|
|
(true for any large function). What is tested and where - who knows?
|
|
</li>
|
|
<li class="listitem" style="list-style-type: square">
|
|
Many checks require similar preparations. This results in code repetitions within the test function.
|
|
</li>
|
|
<li class="listitem" style="list-style-type: square">
|
|
If a fatal error or an exception is caused by any checks within the test function the rest of tests are
|
|
skipped and there is no way to prevent this.
|
|
</li>
|
|
<li class="listitem" style="list-style-type: square">
|
|
No way to perform only checks for a particular subsystem of the tested unit.
|
|
</li>
|
|
<li class="listitem" style="list-style-type: square">
|
|
No summary of how different subsystems of the tested unit performed under in the test.
|
|
</li>
|
|
</ul></div>
|
|
<p class="first-line-indented">
|
|
The above points should make it clear that it's preferable to split <a class="link" href="glossary.html#test-module.def">test module
|
|
</a> into smaller units. These units are test cases. A test case has to be constructed based on some kind of
|
|
function and registered in a test tree, so that the test runner knows how to invoke it. There are different
|
|
possible designs for the test case construction problem: inheritance from the predefined base class, specifically
|
|
named member function and so on. The <acronym class="acronym">UTF</acronym> opted to avoid classed altogether and to use the least intrusive "
|
|
generic callback" approach. The facility, the <acronym class="acronym">UTF</acronym> provides, requires specific function signature and allows
|
|
adopting any function or function object that matches the signature as a test case. The signatures the <acronym class="acronym">UTF</acronym>
|
|
supports are:
|
|
</p>
|
|
<div class="itemizedlist"><ul type="disc">
|
|
<li class="listitem">
|
|
<a class="link" href="test-organization/nullary-test-case.html" title="Nullary function based test case">Nullary function</a>
|
|
</li>
|
|
<li class="listitem">
|
|
<a class="link" href="test-organization/unary-test-case.html" title="Unary function based test case">Unary function</a>
|
|
</li>
|
|
<li class="listitem">
|
|
<a class="link" href="test-organization/test-case-template.html" title="Test case template">Nullary function template</a>
|
|
</li>
|
|
</ul></div>
|
|
<p class="first-line-indented">
|
|
To solve test tree creation problem the <acronym class="acronym">UTF</acronym> provides facilities for
|
|
<a class="link" href="test-organization/test-suite.html" title="Test suite">test suite creation</a>.
|
|
</p>
|
|
<p class="first-line-indented">
|
|
Generic test case construction design used by the <acronym class="acronym">UTF</acronym> causes the test case implementation (test function body)
|
|
and test case creation/registration points to be remote. As a result you may forget to register the test case
|
|
and it's never going to be executed, even though it's present in test file. To alleviate this issue
|
|
the <acronym class="acronym">UTF</acronym> presents facilities for automated (in place) test case creation and registration in the test tree. These
|
|
facilities sacrifice some generality and work for selected test function signatures only. But the result is that
|
|
library users are relieved from the necessity to manually register test cases. These facilities are the most
|
|
user-friendly and are recommended to be used whenever possible. In addition they support automated registration
|
|
of test suites, thus allowing whole test tree to be created without any use of manual registration.
|
|
</p>
|
|
<p class="first-line-indented">
|
|
The single test module may mix both automated and manual test case
|
|
registration. In other words, within the same test module you can have both test cases implemented remotely and
|
|
registered manually in the test module initialization function and test cases that are registered automatically at
|
|
implementation point.
|
|
</p>
|
|
<p class="first-line-indented">
|
|
In some cases it's desirable to allow some "expected" failures in test case without failing a
|
|
test module. To support this request The <acronym class="acronym">UTF</acronym> allows specifying the number of
|
|
<a class="link" href="test-organization/expected-failures.html" title="Expected failures specification">expected failures</a> in a test case.
|
|
</p>
|
|
</div>
|
|
<table xmlns:rev="http://www.cs.rpi.edu/~gregod/boost/tools/doc/revision" width="100%"><tr>
|
|
<td align="left"></td>
|
|
<td align="right"><div class="copyright-footer">Copyright © 2001-2011 Gennadiy Rozental</div></td>
|
|
</tr></table>
|
|
<hr>
|
|
<div class="spirit-nav">
|
|
<a accesskey="p" href="usage-variants/extern-test-runner-variant.html"><img src="../../../../../../doc/src/images/prev.png" alt="Prev"></a><a accesskey="u" href="../user-guide.html"><img src="../../../../../../doc/src/images/up.png" alt="Up"></a><a accesskey="h" href="../../index.html"><img src="../../../../../../doc/src/images/home.png" alt="Home"></a><a accesskey="n" href="test-organization/nullary-test-case.html"><img src="../../../../../../doc/src/images/next.png" alt="Next"></a>
|
|
</div>
|
|
</body>
|
|
</html>
|