1 files changed, 89 insertions, 0 deletions
diff --git a/lib/common_test/doc/src/why_test_chapter.xml b/lib/common_test/doc/src/why_test_chapter.xml
new file mode 100644
index 0000000000..95ff614f87
--- /dev/null
+++ b/lib/common_test/doc/src/why_test_chapter.xml
@@ -0,0 +1,89 @@
+<?xml version="1.0" encoding="latin1" ?>
+<!DOCTYPE chapter SYSTEM "chapter.dtd">
+
+<chapter>
+  <header>
+    <copyright>
+      <year>2003</year><year>2009</year>
+      <holder>Ericsson AB. All Rights Reserved.</holder>
+    </copyright>
+    <legalnotice>
+      The contents of this file are subject to the Erlang Public License,
+      Version 1.1, (the "License"); you may not use this file except in
+      compliance with the License. You should have received a copy of the
+      Erlang Public License along with this software. If not, it can be
+      retrieved online at http://www.erlang.org/.
+    
+      Software distributed under the License is distributed on an "AS IS"
+      basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See
+      the License for the specific language governing rights and limitations
+      under the License.
+    
+    </legalnotice>
+
+    <title>Some thoughts about testing</title>
+    <prepared>Siri Hansen</prepared>
+    <docno></docno>
+    <date></date>
+    <rev></rev>
+    <file>why_test_chapter.xml</file>
+  </header>
+         
+
+  <section>
+    <title>Goals</title>
+
+    <p>It's not possible to prove that a program is correct by
+    testing. On the contrary, it has been formally proven that it is
+    impossible to prove programs in general by testing. Theoretical
+    program proofs or plain examination of code may be viable options
+    for those that wish to certify that a program is correct. The test
+    server, as it is based on testing, cannot be used for
+    certification. Its intended use is instead to (cost effectively)
+    <em>find bugs</em>. A successful test suite is one that reveals a
+    bug. If a test suite results in Ok, then we know very little that
+    we didn't know before.</p>
+
+  </section>
+
+  <section>
+    <title>What to test?</title>
+
+    <p>
+      There are many kinds of test suites. Some concentrate on
+      calling every function or command (in the documented way) in 
+      a certain interface.
+      Some other do the same, but uses all kinds of illegal
+      parameters, and verifies that the server stays alive and rejects
+      the requests with reasonable error codes. Some test suites
+      simulate an application (typically consisting of a few modules of
+      an application), some try to do tricky requests in general, some
+      test suites even test internal functions with help of special
+      load-modules on target.</p>
+
+    <p>Another interesting category of test suites are the ones that
+      check that fixed bugs don't reoccur. When a bugfix is introduced,
+      a test case that checks for that specific bug should be written
+      and submitted to the affected test suite(s).</p>
+
+    <p>Aim for finding bugs. Write whatever test that has the highest
+      probability of finding a bug, now or in the future. Concentrate
+      more on the critical parts. Bugs in critical subsystems are a lot
+      more expensive than others.</p>
+
+    <p>Aim for functionality testing rather than implementation
+      details. Implementation details change quite often, and the test
+      suites should be long lived. Often implementation details differ
+      on different platforms and versions. If implementation details
+      have to be tested, try to factor them out into separate test
+      cases. Later on these test cases may be rewritten, or just
+      skipped.</p>
+
+    <p>Also, aim for testing everything once, no less, no more. It's
+      not effective having every test case fail just because one
+      function in the interface changed.</p>
+
+  </section>
+
+</chapter>
+