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

Behaviour Driven Testing und automatische Unit-Test-Generierung

Open

Anwendung