17. “Today a usual technique is
to make a program
and then to test it.“
18. The Humble Programmer (1972) - Dijkstra
Argument three is based on the constructive approach to the problem of program
correctness. Today a usual technique is to make a program and then to test it. But:
program testing can be a very effective way to show the presence of bugs, but is
hopelessly inadequate for showing their absence. The only effective way to raise the
confidence level of a program significantly is to give a convincing proof of its
correctness. But one should not first make the program and then prove its correctness,
because then the requirement of providing the proof would only increase the poor
programmer’s burden. On the contrary: the programmer should let correctness proof
and program grow hand in hand. Argument three is essentially based on the following
observation. If one first asks oneself what the structure of a convincing proof would be
and, having found this, then constructs a program satisfying this proof’s requirements,
then these correctness concerns turn out to be a very effective heuristic guidance.
31. “Write a test, make it run, make it right.
To make it run,
one is allowed to violate principles of good design.
Making it right means to refactor it.”
Dave Hoover
39. Code Kata: The GREETING KATA
/testdouble/contributing-tests/wiki/Greeting-Kata
/swkBerlin/kata-bootstraps
40. Retrospective
- “TDD as if you meant it”
- Design decisions
- Inputs&Outputs vs User Stories
- Test names (intention/behaviour, no implementation)
- Too much logic in tests
- Actual vs Expected
45. Code Kata: BANK ACCOUNT KATA
/swkBerlin/kata-bootstraps
Given a client makes a deposit of 1000 on 10-01-2012
And a deposit of 2000 on 13-01-2012
And a withdrawal of 500 on 14-01-2012
When she prints her bank statement
Then she would see
date || credit || debit || balance
14/01/2012 || || 500.00 || 2500.00
13/01/2012 || 2000.00 || || 3000.00
10/01/2012 || 1000.00 || || 1000.00
NO COMPUTERS!!
50. Retrospective
- Design decisions
- Inputs&Outputs vs User Stories
- Test names (intention/behaviour, no implementation)
- Too much logic in tests
- Additional code for testing
51. Additional code for testing
- Equality Pollution
- JSON, XML, … readers
- Additional features