@@ -29,9 +29,12 @@ slideOptions:
29
29
30
30
## Learning Goals of the Chapter
31
31
32
- - Justify the effort of developing testing infrastructure for simulation software
33
- - Discern the concepts of unit testing, integration testing and regression testing with the perspective of simulation software
34
- - Work with the Python testing frameworks ` pytest ` and ` unittest `
32
+ - Know the need of developing testing infrastructure for simulation software.
33
+ - Explain the concepts of unit testing, integration testing and regression testing with the perspective of simulation software.
34
+ - Write tests using the Python libraries ` pytest ` and ` unittest ` .
35
+ - Write tests in C++ using ` Boost.Test ` .
36
+ - Explain the concepts of automation workflows in RSE.
37
+ - Write automation workflows using GitHub Actions and GitLab CI.
35
38
36
39
---
37
40
@@ -48,7 +51,7 @@ slideOptions:
48
51
- Improve software reliability and reproducibility.
49
52
- Make sure that changes (bugfixes, new features) do not affect other parts of software.
50
53
- Generally all software is better off being tested regularly. Possible exceptions are very small codes with single users.
51
- - Ensure that a released version of a software actually works.
54
+ - Ensure that a distributed/packaged software actually works.
52
55
53
56
---
54
57
@@ -87,18 +90,18 @@ assert condition, "message"
87
90
88
91
---
89
92
90
- ## Unit Testing
93
+ ## Unit testing
91
94
92
95
- Catching errors with assertions is good but preventing them is better!
93
96
- A * unit* is a single function in one situation.
94
97
- A situation is one amongst many possible variations of input parameters.
95
98
- User creates the expected result manually.
96
- - Fixture is the set of inputs used to generate an actual result.
99
+ - A fixture is a set of inputs used to generate an actual result.
97
100
- Actual result is compared to the expected result, for e.g. using an assertion statement.
98
101
99
102
---
100
103
101
- ## Integration Testing
104
+ ## Integration testing
102
105
103
106
- Test whether several units work in conjunction.
104
107
- * Integrate* units and test them together in an * integration* test.
@@ -108,7 +111,7 @@ assert condition, "message"
108
111
109
112
---
110
113
111
- ## Regression Testing
114
+ ## Regression testing
112
115
113
116
- Generating an expected result is not possible in some situations.
114
117
- Compare the current actual result with a previous actual result.
@@ -120,13 +123,13 @@ assert condition, "message"
120
123
121
124
## Test Coverage
122
125
123
- - Coverage is the amount of code a test touches in one run .
126
+ - Coverage is the amount of code a test runs through .
124
127
- Aim for high test coverage.
125
- - There is a trade-off: high test coverage vs. effort in test development
128
+ - There is a trade-off: extremely high test coverage vs. effort in test development
126
129
127
130
---
128
131
129
- ## Comparing Floating -point Variables
132
+ ## Comparing floating -point variables
130
133
131
134
- Very often quantities in simulation software are ` float ` / ` double ` .
132
135
- Such quantities cannot be compared to exact values, an approximation is necessary.
@@ -136,26 +139,23 @@ assert condition, "message"
136
139
137
140
---
138
141
139
- ## Test-driven Development (TDD)
142
+ ## Test-driven development (TDD)
140
143
141
- - Principle is to write a test and then write a code to fulfill the test.
144
+ - Principle of writing a test and then write a code to fulfill the test.
142
145
- Advantages:
143
- - In the end user ends up with a test alongside the code .
146
+ - Leads to a robust test along with the implementation .
144
147
- Eliminates confirmation bias of the user.
145
- - Writing tests gives clarity on what the code is supposed to do.
146
- - Disadvantage: known to not improve productivity.
148
+ - Facilitates continuous integration.
149
+ - Reduces need for debugging.
150
+ - Disadvantages:
151
+ - False security from tests.
152
+ - Neglect of overall design.
147
153
148
- ---
149
-
150
- ## Checking-driven Development (CDD)
151
-
152
- - Developer performs spot checks; sanity checks at intermediate stages
153
- - Simulation software often has heuristics which are easy to determine.
154
- - Keep performing same checks at different stages of development to ensure the code works.
154
+ Source: https://en.wikipedia.org/wiki/Test-driven_development
155
155
156
156
---
157
157
158
- ## Verifying a Test
158
+ ## Verifying a test
159
159
160
160
- Test written as part of a bug-fix:
161
161
- Reproduce the bug in the test by ensuring that the test fails.
0 commit comments