Content

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

Behaviour Driven Testing und automatische Unit-Test-Generierung

UPact - Automatisiertes Testen

/wiki/spaces/1HEA/pages/3739667