Test Driven Development

Slides are at https://tdd.josephabell.co.uk

Wikipedia says:

Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle.

  • Requirements are turned into very specific test cases.
  • The software is improved to pass the new tests, only.


  • Tickets should become more clear.
  • By the end of analysis the tickets should have unambiguous requirements.
  • Tests should cover the requirements of the ticket and not assumptions of the developer.
  • After the tests are written, if the ticket needs to go back to next, another developer could write the code to fix the tests, and pass all requirements of the ticket.
  • The tests will explain the developer's thought process, which will aid clarity to other members of the team.

More Benefits

  • QA can be involved from the start of the ticket, to catch areas the Devs have missed.
  • Less feature creep. If a Dev feels the need to add more tests after analysis, they should check whether the extra work is out of scope.
  • QAs get evidence that the requirements for a ticket are tested and fulfilled.
  • Communication between Ticket Owner, Dev and QA throughout the life of the ticket.

TDD in Practice


  • If the ticket has some ambiguity, it could be that the ticket has not met our definition of ready.
  • If the ambiguity is an implementation detail, remove all ambiguity during the analysis phase.
  • If the ticket doesn't have a set of requirements in the description, add them.
  • Make sure that the requirements include different scenarios if needed.


  • If a requirement cannot be easily translated into a test, rewrite it until it can be.
  • If more requirements have been added, get agreement that the new requirements are in scope. It could be that a new ticket is needed.
  • Check with the team to make sure requirements and tests cover all they need to before entering the development phase of the ticket.
  • Use analysis as a requirement and test review stage.

Writing tests

  • Write tests during the analysis stage.
  • Start small.
  • Test iteratively.
  • Tests should follow logically from the previous tests.
  • Only write tests that help meet the requirements.
  • Write the tests before writing code.
  • If the test fails before writing your code, this means that you are testing the right thing.
  • If the test already passes before you write any code because previous code covers your test, break your code to make sure that the test fails as expected. Fix your code again afterwards.

Writing code

  • Only write code that fixes tests.
  • If code isn't relevant to a test, it needs a test or is out of scope.
  • Fix tests in the most simple way possible.
  • Fix one test at a time.
  • Keep previous tests running when fixing a new test to stop you breaking previous functionality.

Merge Requests

Now all the requirements have passing tests, check to see if the code can be improved. After you are happy, ask your favourite code enforcer to check your work.


We are writing code to help people play a game called Buffalo. The rules:

  • If the minute hand of a clock is on the right, between 0 and 29 minutes, drink with your right hand.
  • If the minute hand of a clock is on the left, between 30 and 59 minutes, drink with your left hand.
  • If a player is caught drinking with the wrong hand, bad things happen.


We want a function called buffalo that takes a number between 0 and 59, and returns either the word 'right' or 'left' depending on the number's value.
  • If the number is between 0 and 29, return 'right'.
  • If the number is between 30 and 59, return 'left'.
  • If the number is less than 0 or greater than 59, return nothing.

Demo Time!

I'm almost done, promise.


We should have tests that match the initial requirements, and code that fulfills the tests.

Make sure that your tests cover the requirements, and the code is the simplest it can be while passing the tests.