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 than testGet)
• 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