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

About Jaroslaw Pawlak

I have done MSci in Computer Science at King’s College London and currently work as Software Engineer specialising in Java. I spend most of my time in front of computer improving my programming (and other) skills or just relaxing with a good game. I also train some sports but at the moment I am not a member of any club. I love cycling and volleyball, but I have also played a lot of football, tennis and trained martial arts.

Posted on August 30, 2014, in Test Driven Development. Bookmark the permalink. Leave a comment.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s

%d bloggers like this: