1  How we should structure tests to improve velocity and reliability.
 2  
 3  # Pages
 4  
 5  [Roadmap](Roadmap "wikilink") \[CI Pipeline (Travis CI)\]\]
 6  
 7  # Terminology
 8  
 9  **Unit tests** verify if the smallest structure of a program, like
10  functions or methods, work properly. They should test all branches in a
11  given function and aim for 100% coverage.
12  
13  **Integration tests** verify if separate components can work together.
14  For instance, verify if `jail` can work with the `rpc.Client` using a
15  `net/http/httptest.Server` mock. It’s important to keep integration
16  tests fast, reliable and predictable.
17  
18  **E2e tests** verify if a program works properly with external systems.
19  It should resemble the production setup as close as possible. In our
20  case, e2e tests would use any public testnet.
21  
22  # Type of tests
23  
24  ![03-Piramides-03-03.png](03-Piramides-03-03.png
25  "03-Piramides-03-03.png")
26  
27  ## Unit tests
28  
29  **Features**
30  
31    - the first line of defense against bugs
32    - lightning fast
33    - lots of small functions each testing a single case
34    - cover only code within its own package
35    - the obligatory part of CI on every stage
36  
37  **When write**
38  
39    - when you introduce a new function
40    - add a functionality to the existing function
41    - modify an existing function
42  
43  **When run**
44  
45    - after any change of code
46    - in each CI job
47  
48  ## Components/Integration/API Tests
49  
50  **Features**
51  
52    - verify that components can work with each other
53    - use mocks heavily
54    - lightning fast
55    - do not require external systems
56    - the obligatory part of CI on every stage
57  
58  **When write**
59  
60    - a component got new exported functions
61    - an existing exported function/struct/interface changed its shape or
62      logic
63  
64  **When run**
65  
66    - before commit
67    - in each CI job
68  
69  ## e2e tests (GUI in the image)
70  
71  **Features**
72  
73    - verify if compliant with other systems
74    - take significantly more time
75  
76  **When write**
77  
78    - a new system feature was added (e.g. new protocol support)
79  
80  **When run**
81  
82    - before preparing a release
83    - periodically in CI job
84    - manually if needed
85  
86  # Private blockchain and CI pipelines
87  
88  -----
89  
90  A private blockchain can be used in e2e tests and could be a part of a
91  pull request CI pipeline because the private network should provide much
92  higher reliability than public testnets.
93  
94  The public testnets could be a part of a release CI pipeline and also
95  run periodically every 1 hour or so. The idea is that if the public
96  testnet is unavailable, it does not affect the development but it can
97  affect release.
98  
99  [Continous Delivery](Continous_Delivery "wikilink")