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

« back to all changes in this revision

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

• browse files at revision 17
• compare with another revision
• download diff
• download tarball
• view history from revision 17

Show diffs side-by-side

added

removed

lib/common_test/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>2003</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>Some thoughts about testing</title>

 

27

    <prepared>Siri Hansen</prepared>

 

28

    <docno></docno>

 

29

    <date></date>

 

30

    <rev></rev>

 

31

  </header>

 

32

         

 

33

 

 

34

  <section>

 

35

    <title>Goals</title>

 

36

 

 

37

    <p>It's not possible to prove that a program is correct by

 

38

    testing. On the contrary, it has been formally proven that it is

 

39

    impossible to prove programs in general by testing. Theoretical

 

40

    program proofs or plain examination of code may be viable options

 

41

    for those that wish to certify that a program is correct. The test

 

42

    server, as it is based on testing, cannot be used for

 

43

    certification. Its intended use is instead to (cost effectively)

 

44

    <em>find bugs</em>. A successful test suite is one that reveals a

 

45

    bug. If a test suite results in Ok, then we know very little that

 

46

    we didn't know before.</p>

 

47

 

 

48

  </section>

 

49

 

 

50

  <section>

 

51

    <title>What to test?</title>

 

52

 

 

53

    <p>

 

54

      There are many kinds of test suites. Some concentrate on

 

55

      calling every function or command (in the documented way) in 

 

56

      a certain interface.

 

57

      Some other do the same, but uses all kinds of illegal

 

58

      parameters, and verifies that the server stays alive and rejects

 

59

      the requests with reasonable error codes. Some test suites

 

60

      simulate an application (typically consisting of a few modules of

 

61

      an application), some try to do tricky requests in general, some

 

62

      test suites even test internal functions with help of special

 

63

      loadmodules on target.</p>

 

64

 

 

65

    <p>Another interesting category of test suites are the ones that

 

66

      check that fixed bugs don't reoccur. When a bugfix is introduced,

 

67

      a test case that checks for that specific bug should be written

 

68

      and submitted to the affected test suite(s).</p>

 

69

 

 

70

    <p>Aim for finding bugs. Write whatever test that has the highest

 

71

      probability of finding a bug, now or in the future. Concentrate

 

72

      more on the critical parts. Bugs in critical subsystems are a lot

 

73

      more expensive than others.</p>

 

74

 

 

75

    <p>Aim for functionality testing rather than implementation

 

76

      details. Implementation details change quite often, and the test

 

77

      suites should be long lived. Often implementation details differ

 

78

      on different platforms and versions. If implementation details

 

79

      have to be tested, try to factor them out into separate test

 

80

      cases. Later on these test cases may be rewritten, or just

 

81

      skipped.</p>

 

82

 

 

83

    <p>Also, aim for testing everything once, no less, no more. It's

 

84

      not effective having every test case fail just because one

 

85

      function in the interface changed.</p>

 

86

 

 

87

  </section>

 

88

 

 

89

</chapter>

 

90

 

• Older »

Loggerhead is a web-based interface for Breezy
Version: 2.0.1