aboutsummaryrefslogtreecommitdiffstats
path: root/lib/common_test/doc/src/why_test_chapter.xml
diff options
context:
space:
mode:
Diffstat (limited to 'lib/common_test/doc/src/why_test_chapter.xml')
-rw-r--r--lib/common_test/doc/src/why_test_chapter.xml43
1 files changed, 21 insertions, 22 deletions
diff --git a/lib/common_test/doc/src/why_test_chapter.xml b/lib/common_test/doc/src/why_test_chapter.xml
index 15eb1aaed4..ff6000628b 100644
--- a/lib/common_test/doc/src/why_test_chapter.xml
+++ b/lib/common_test/doc/src/why_test_chapter.xml
@@ -22,7 +22,7 @@
</legalnotice>
- <title>Some thoughts about testing</title>
+ <title>Some Thoughts about Testing</title>
<prepared>Siri Hansen</prepared>
<docno></docno>
<date></date>
@@ -34,54 +34,53 @@
<section>
<title>Goals</title>
- <p>It's not possible to prove that a program is correct by
+ <p>It is 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
+ program proofs or plain examination of code can be viable options
+ for those wishing 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>
+ bug. If a test suite results in OK, then we know very little that
+ we did not know before.</p>
</section>
<section>
- <title>What to test?</title>
+ <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
+ Some others do the same, but use all kinds of illegal
+ parameters, and verify 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
+ an application), some try to do tricky requests in general, and some
test suites even test internal functions with help of special
- load-modules on target.</p>
+ 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>Another interesting category of test suites is the one
+ checking that fixed bugs do not reoccur. When a bugfix is introduced,
+ a test case that checks for that specific bug is written
+ and submitted to the affected test suites.</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 on the critical parts. Bugs in critical subsystems are much
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
+ suites are to be long lived. Implementation details often 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>
+ must be tested, try to factor them out into separate test
+ cases. These test cases can later be rewritten or 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
+ <p>Also, aim for testing everything once, no less, no more. It is
+ not effective having every test case fail only because one
function in the interface changed.</p>
</section>