Skip to content

Commit 1f72790

Browse files
committed
Rework learning goals of Chapter 5, and introduction to testing slides
1 parent 4bd9f2f commit 1f72790

File tree

1 file changed

+24
-24
lines changed

1 file changed

+24
-24
lines changed

05_testing_and_ci/intro_slides.md

Lines changed: 24 additions & 24 deletions
Original file line numberDiff line numberDiff line change
@@ -29,9 +29,12 @@ slideOptions:
2929

3030
## Learning Goals of the Chapter
3131

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.
3538

3639
---
3740

@@ -48,7 +51,7 @@ slideOptions:
4851
- Improve software reliability and reproducibility.
4952
- Make sure that changes (bugfixes, new features) do not affect other parts of software.
5053
- 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.
5255

5356
---
5457

@@ -87,18 +90,18 @@ assert condition, "message"
8790

8891
---
8992

90-
## Unit Testing
93+
## Unit testing
9194

9295
- Catching errors with assertions is good but preventing them is better!
9396
- A *unit* is a single function in one situation.
9497
- A situation is one amongst many possible variations of input parameters.
9598
- 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.
97100
- Actual result is compared to the expected result, for e.g. using an assertion statement.
98101

99102
---
100103

101-
## Integration Testing
104+
## Integration testing
102105

103106
- Test whether several units work in conjunction.
104107
- *Integrate* units and test them together in an *integration* test.
@@ -108,7 +111,7 @@ assert condition, "message"
108111

109112
---
110113

111-
## Regression Testing
114+
## Regression testing
112115

113116
- Generating an expected result is not possible in some situations.
114117
- Compare the current actual result with a previous actual result.
@@ -120,13 +123,13 @@ assert condition, "message"
120123

121124
## Test Coverage
122125

123-
- Coverage is the amount of code a test touches in one run.
126+
- Coverage is the amount of code a test runs through.
124127
- 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
126129

127130
---
128131

129-
## Comparing Floating-point Variables
132+
## Comparing floating-point variables
130133

131134
- Very often quantities in simulation software are `float` / `double`.
132135
- Such quantities cannot be compared to exact values, an approximation is necessary.
@@ -136,26 +139,23 @@ assert condition, "message"
136139

137140
---
138141

139-
## Test-driven Development (TDD)
142+
## Test-driven development (TDD)
140143

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.
142145
- Advantages:
143-
- In the end user ends up with a test alongside the code.
146+
- Leads to a robust test along with the implementation.
144147
- 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.
147153

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
155155

156156
---
157157

158-
## Verifying a Test
158+
## Verifying a test
159159

160160
- Test written as part of a bug-fix:
161161
- Reproduce the bug in the test by ensuring that the test fails.

0 commit comments

Comments
 (0)