TDD learning materials
Recently I have been giving internal presentation in Gamesys about how to do Test Driven Development. A simple exercise is available in my github repository. Extra thanks to Mani Sarkar for his input in preparing this exercise.
TDD rules and hints
- don’t write production code unless there is a failing test
- refactoring is fine, but refrain from it if there are no tests (e.g. legacy code) and don’t do this if tests are failing
- write minimal code to satisfy the test
- write minimal amount of tests which are necessary to fail
- if you write a new test and it is passing, it means that it may not be needed (however you may still want to test some critical components)
- if two tests are always failing together or always passing together, one of them is probably redundant
- always see the test fail and for the right reason
- when writing tests for existing code, never change the test to see it fail, break implementation instead
- when writing tests for existing code, consider removing all production code and keep adding it back piece by piece, only what is needed for the test to pass
- give a test a meaningful name, describe what it does (e.g.
retrievesAllPostedMessages
rather thantestGet
) - test should test only one thing – one logical assertion
- it’s worth to have only one assertion statement as it usually gives better diagnostics
- consider writing your assertion first and working backwards
- once feature is implemented and all tests are green, refactor production code
- remove all smells (e.g. duplications)
- maximise clarity (e.g. extract code to methods with meaningful names)
- maintain your tests – it’s not a “second class citizen”, it’s as important as production code
- start writing tests from the simplest cases and keep adding more complex cases (triangulation)
- test behaviour, not implementation
- isolate the tests
- test should not be using production code as expectation, the expected values should be hardcoded within the test
- test should not be relying on another test
- you should be able to run your tests (or any subset of them) in any order
- you should be able to run your unit tests in parallel so avoid mutable static fields
- tests should be cleaning after themselves, otherwise you may find other tests failing and it will be very difficult to find the reason
Posted on August 30, 2014, in Test Driven Development. Bookmark the permalink. Leave a comment.
Leave a comment
Comments 0