← Back to branch summary

~rdoering/ubuntu/karmic/erlang/fix-535090

« back to all changes in this revision

Viewing changes to lib/test_server/doc/src/why_test_chapter.xml

  • Committer: Bazaar Package Importer
  • Author(s): Sergei Golovan
  • Date: 2009-02-15 16:42:52 UTC
  • mfrom: (1.1.13 upstream)
  • mto: (3.3.1 squeeze)
  • mto: This revision was merged to the branch mainline in revision 17.
  • Revision ID: james.westby@ubuntu.com-20090215164252-dxpjjuq108nz4noa
Upload to unstable after lenny is released.

Show diffs side-by-side

added added

removed removed

Lines of Context:
lib/test_server/doc/src/why_test_chapter.xml
 
1
<?xml version="1.0" encoding="latin1" ?>
 
2
<!DOCTYPE chapter SYSTEM "chapter.dtd">
 
3
 
 
4
<chapter>
 
5
  <header>
 
6
    <copyright>
 
7
      <year>2002</year>
 
8
      <year>2008</year>
 
9
      <holder>Ericsson AB, All Rights Reserved</holder>
 
10
    </copyright>
 
11
    <legalnotice>
 
12
  The contents of this file are subject to the Erlang Public License,
 
13
  Version 1.1, (the "License"); you may not use this file except in
 
14
  compliance with the License. You should have received a copy of the
 
15
  Erlang Public License along with this software. If not, it can be
 
16
  retrieved online at http://www.erlang.org/.
 
17
 
 
18
  Software distributed under the License is distributed on an "AS IS"
 
19
  basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See
 
20
  the License for the specific language governing rights and limitations
 
21
  under the License.
 
22
 
 
23
  The Initial Developer of the Original Code is Ericsson AB.
 
24
    </legalnotice>
 
25
 
 
26
    <title>Why Test</title>
 
27
    <prepared>Siri Hansen</prepared>
 
28
    <docno></docno>
 
29
    <date></date>
 
30
    <rev></rev>
 
31
  </header>
 
32
 
 
33
  <section>
 
34
    <title>Goals</title>
 
35
    <p>It's not possible to prove that a program is correct by
 
36
      testing. On the contrary, it has been formally proven that it is
 
37
      impossible to prove programs in general by testing. Theoretical
 
38
      program proofs or plain examination of code may be viable options
 
39
      for those that wish to certify that a program is correct. The test
 
40
      server, as it is based on testing, cannot be used for
 
41
      certification. Its intended use is instead to (cost effectively)
 
42
      <em>find bugs</em>. A successful test suite is one that reveals a
 
43
      bug. If a test suite results in Ok, then we know very little that
 
44
      we didn't know before.
 
45
      </p>
 
46
  </section>
 
47
 
 
48
  <section>
 
49
    <title>What to test?</title>
 
50
    <p>There are many kinds of test suites. Some concentrate on
 
51
      calling every function in the interface to some module or
 
52
      server. Some other do the same, but uses all kinds of illegal
 
53
      parameters, and verifies that the server stays alive and rejects
 
54
      the requests with reasonable error codes. Some test suites
 
55
      simulate an application (typically consisting of a few modules of
 
56
      an application), some try to do tricky requests in general, some
 
57
      test suites even test internal functions.
 
58
      </p>
 
59
    <p>Another interesting category of test suites are the ones that
 
60
      check that fixed bugs don't reoccur. When a bugfix is introduced,
 
61
      a test case that checks for that specific bug should be written
 
62
      and submitted to the affected test suite(s).
 
63
      </p>
 
64
    <p>Aim for finding bugs. Write whatever test that has the highest
 
65
      probability of finding a bug, now or in the future. Concentrate
 
66
      more on the critical parts. Bugs in critical subsystems are a lot
 
67
      more expensive than others.
 
68
      </p>
 
69
    <p>Aim for functionality testing rather than implementation
 
70
      details. Implementation details change quite often, and the test
 
71
      suites should be long lived. Often implementation details differ
 
72
      on different platforms and versions. If implementation details
 
73
      have to be tested, try to factor them out into separate test
 
74
      cases. Later on these test cases may be rewritten, or just
 
75
      skipped.
 
76
      </p>
 
77
    <p>Also, aim for testing everything once, no less, no more. It's
 
78
      not effective having every test case fail just because one
 
79
      function in the interface changed.
 
80
      </p>
 
81
  </section>
 
82
 
 
83
  <section>
 
84
    <title>How much to test</title>
 
85
    <p>There is a unix shell script that counts the number of non
 
86
      commented words (lines and characters too) of source code in each
 
87
      application's test directory and divides with the number of such
 
88
      source words in the src directory. This is a measure of how much
 
89
      test code there is.
 
90
      </p>
 
91
    <p>There has been much debate over how much test code, compared to
 
92
      production code, should be written in a project. More test code
 
93
      finds more bugs, but test code needs to be maintained just like
 
94
      the production code, and it's expensive to write it in the first
 
95
      place. In several articles from relatively mature software
 
96
      organizations that I have read, the amount of test code has been
 
97
      about the same as the production code.  </p>
 
98
    <p>In OTP, at the time of
 
99
      writing, few applications come even close to this, some have no
 
100
      test code at all.
 
101
      </p>
 
102
 
 
103
    <section>
 
104
      <title>Full coverage</title>
 
105
      <p>It is possible to cover compile the modules being tested
 
106
        before running the test suites. Doing so displays which branches
 
107
        of the code that are tested by the test suite, and which are
 
108
        not. Many use this as a measure of a good test suite. When every
 
109
        single line of source code is covered once by the test suite,
 
110
        the test suite is finished.
 
111
        </p>
 
112
      <p>A coverage of 100% still proves nothing, though. It doesn't
 
113
        mean that the code is error free, that everything is tested. For
 
114
        instance, if a function contains a division, it has to be
 
115
        executed at least twice. Once with parameters that cause
 
116
        division by zero, and once with other parameters.
 
117
        </p>
 
118
      <p>High degree of coverage is good of course, it means that no
 
119
        major parts of the code has been left untested. It's another
 
120
        question whether it's cost effective. You're only likely to find
 
121
        50% more bugs when going from 67% to 100% coverage, but the work
 
122
        (cost) is maybe 200% as large, or more, because reaching all of
 
123
        those obscure branches is usually complicated.
 
124
        </p>
 
125
      <p>Again, the reason for testing with the test server is to find
 
126
        bugs, not to create certificates of valid code. Maximizing the
 
127
        number of found bugs per hour probably means not going for 100%
 
128
        coverage. For some module the optimum may be 70%, for some other
 
129
        maybe 250%. 100% shouldn't be a goal in itself.</p>
 
130
    </section>
 
131
 
 
132
    <section>
 
133
      <title>User interface testing</title>
 
134
      <p>It is very difficult to do sensible testing of user
 
135
        interfaces, especially the graphic ones. The test server has
 
136
        some support for capturing the text I/O that goes to the user,
 
137
        but none for graphics. There are several tools on the market
 
138
        that help with this.</p>
 
139
    </section>
 
140
  </section>
 
141
</chapter>
 
142