Effective Unit Testing
- Raphael Rietmann
- Kay Vonarburg
Content
Kurz Einführung
Einfaches Einführungsvideo
Effective Unit Testing - Eliotte Rusty Harold
https://www.youtube.com/watch?v=fr1E9aVnBxw
Summary (by RRI 16.10.2020)
1 Fix Input Fix Output
Fixed known input, fixed known output: ex.: sqr(9) = 3
Avoid parametrization
If the output is unknown, test whether there is any at all
Exeptions (Fehlerbehandlungen) sollten für Fehlerzustände geschrieben werden, welche man erwartet; Assertions (Zusicherungen) für Fehlerzustände, die niemals auftreten sollten.
: Assert(s != Null)
No random input
Do not use constants from the code, but literals
Changes in constants are noticed
Test is independent of implementation
2 Write the tests first
- Write the tests before the implementation:
- Helps to get clear what the functionality of the unit should be
- Better interface
- Test is independent of implementation
- Changes in implementation -> no change in test
- Good code coverage for free
- Make sure the test can fail
3 Why Unit Tests
- Each test tests exactly one thing
- One assert per test method
- Tests must be independent
- order independent
- may be run in parallel
- must not interfere with each other
- do not share data between tests
- share setup in a fixture, not the same method
4 Speed
- a single test in a second or less
- a complete suite a minute or less
- separate larger suites
- faster tests first
5 Passing Tests Produce No Output
- pass or fail, nothing else
- if necessary, silence loggers
6 Failing Tests Produce Clear Output
- unambiguous error messages
- rotate test data
- not always 666 as input, makes it easier to find error
7 Flakiness
- once fail, once pass, no idea why (diff time, diff sys)
- time dependence
- network availability
- explicit randomness (implemented in the test)
- multithreading
- system skew
- assumptions about operating sys
- floating point roundoff
- integer width
- default character set
- avoid conditional logic in tests
- fixed in fixed out, no choice in the middle
8 Debugging
- write a failing test before you fix the bug
- helps understanding the bug
- if the test passes, the bug is not what you think
9 Refactoring
break the code before refactoring
if the tests pass a test is missing
10 Development Practices
continuous integration (häufiges mergen in master)
submit queue:
pull request
build server merges into a branch
build server runs tests
only if tests pass build server commits to master
never allow check-in if a test is failing
if faulty code is merged, roll back first, ask questions later, no patches
a red test blocks all merges, no merges before all green