|
Boost-Commit : |
From: daniel_james_at_[hidden]
Date: 2007-11-10 11:03:37
Author: danieljames
Date: 2007-11-10 11:03:37 EST (Sat, 10 Nov 2007)
New Revision: 40992
URL: http://svn.boost.org/trac/boost/changeset/40992
Log:
Remove the test policy page, now that it's in the new site. Refs #1372.
Removed:
trunk/more/test_policy.htm
Deleted: trunk/more/test_policy.htm
==============================================================================
--- trunk/more/test_policy.htm 2007-11-10 11:03:37 EST (Sat, 10 Nov 2007)
+++ (empty file)
@@ -1,100 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html>
-
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
-<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
-<meta name="ProgId" content="FrontPage.Editor.Document">
-<title>Boost Test Policies and Protocols</title>
-</head>
-
-<body bgcolor="#FFFFFF" text="#000000">
-
-<table border="1" bgcolor="#007F7F" cellpadding="2">
- <tr>
- <td bgcolor="#FFFFFF"><img src="../boost.png" alt="boost.png (6897 bytes)" width="277" height="86"></td>
- <td>Home</td>
- <td>Libraries</td>
- <td>People</td>
- <td>FAQ</td>
- <td>More</td>
- </tr>
-</table>
-<h1>Boost Test Policies and Protocols</h1>
-<p>The Boost libraries are intended to be both reliable and portable.
-Every experienced programmer knows that means each library must be tested against a suitable number of test cases, on a wide range of platforms,
-and then tested again (regression tested) every time a change is made and before
-every release. </p>
-<p>"Quality assurance based on a wide range of targeted tests" as one
-of the key answers to C.A.R
-Hoare's question
-"How did software get so reliable without proof."</p>
-<h2>Regression test</h2>
-<p>Boost uses an automatic regression test suite which generates HTML
-<a href="../status/compiler_status.html">compiler
-status tables</a>.</p>
-<h2>Test Policy</h2>
-<h3>Required</h3>
-<ul>
- <li>Every Boost library should supply one or more suitable test programs to be
- exercised by the Boost regression test suite. In addition to
- the usual compile-link-run tests expecting successful completion,
- compile-only or compile-and-link-only tests may be performed, and success
- for the test may be defined as failure of the steps.</li>
- <li>Test program execution must report errors by returning a non-zero value. They
- may also write to stdout or stderr, but that output should be relatively
- brief. Regardless of other output, a non-zero return value is the only
- way the regression test framework will recognize an error has
- occurred. Note that test programs to be included in the status tables must
- compile, link, and run quickly since the tests are executed many, many,
- times.</li>
- <li>Libraries with time consuming tests should be divided into a
- fast-execution basic test program for the status tables, and a separate
- full-coverage test program for exhaustive test cases. The basic test
- should concentrate on compilation issues so that the status tables
- accurately reflect the library's likelihood of correct compilation on a
- platform.</li>
- <li>If for any reason the usual test policies do not apply to a particular
- library, an alternate test strategy must be implemented.</li>
- <li>A Jamfile to drive the
- regression tests for the library. </li>
-</ul>
-<h3>Optional (but highly recommended)</h3>
-<p>The Boost Test Library provides many
-useful components which ease the construction of test programs.</p>
-<ul>
- <li>Use the library's
- Test Tools for the construction of simple test
- programs that do not need much structure.</li>
- <li>Use the library's
- <a href="../libs/test/doc/components/utf/index.html">Unit Test
- Framework</a> for the construction of more complex test programs that need to
- be structured into individual tests
- and test suites.</li>
-</ul>
-<h2>Suggested Protocol for Fixing Bugs or Adding Features.</h2>
-<ul>
- <li>First, add regression test cases that detects the bug or tests the
- feature. Sometimes adding one case suggests similar untested cases, and they
- are added too.</li>
- <li>Second, for bugs, run the regression test and verify that the bug is now
- detected.</li>
- <li>Third, then, and only then, fix the bug or add the feature.</li>
- <li>Finally, rerun the full regression tests - sometimes the change breaks
- something else.</li>
-</ul>
-<h2>History</h2>
-<p>See Regression Test History.</p>
-<h2>Acknowledgements</h2>
-<p>Written by Beman Dawes. Jens Maurer, Paul Moore, Gary Powell and Jeremy Siek contributed helpful suggestions.</p>
-<hr>
-<p>Revised <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->08 January, 2004<!--webbot bot="Timestamp" endspan i-checksum="38708" -->
-</p>
-<p>© Copyright Beman Dawes 2001</p>
-<p>Distributed under the Boost Software License, Version 1.0. (See
-accompanying file LICENSE_1_0.txt or copy
-at http://www.boost.org/LICENSE_1_0.txt)</p>
-
-</body>
-
-</html>
Boost-Commit list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk