We are creatures of habit, and our habits, good or not drive us to achieve results we aim for.
This presentation walks you through how 13 Good Habits of TDD programming have evolved into a refined list of such habits.
And when a group of talented craftsmen look at them again, take it to a newer level
27. @theNeomatrix369 @pedromsantos
Principles
- tests should test one thing only
- test one logical assertion
- don't mix assertions of state and collaboration in the same test
- modifications of production code should only break related test cases
- each test should be self-contained, including data
- ensure tests are independent of each other
- don't refactor with a failing test
- organise your unit test projects to reflect your production code
- keep your tests and production code separate
- do not use production data and code to test production code
- if your tests are difficult to write or maintain, consider changing the design
28. @theNeomatrix369 @pedromsantos
Red phase
- create more specific tests to drive a more generic solution (Triangulate)
- give your tests meaningful names (behaviour / goal-oriented) that reflect your
production system
- write the assertion first and work backwards
- see the test fail for the right reason
- ensure you have meaningful feedback from failing tests
29. @theNeomatrix369 @pedromsantos
Green phase
- write the simplest code to pass the test
- write any code that makes you get to the refactor phase quicker
- it is okay to write any code that you might improve at a later stage
30. @theNeomatrix369 @pedromsantos
Refactor phase
- refactor aggressively and constantly
- treat tests as first class code
- use the IDE to refactor quickly and safely
- refactor production and test code independently (except changing public
interfaces)