TDD Lab

README.md

http://goo.gl/AHMJY4

Test-Driven Development Lab

One of the biggest problems we have in commercial software engineering is "quality", ie bugs/breakages/failures. These can be expensive, embarrassing and even fatal. The biggest cause of quality issues is unintended complexity introduced by writing more and cleverer code than is required to solve the problem at hand. TDD is a disciplined approach to solving a problem in a step-wise fashion by writing the smallest amount of well-organised code possible. It also helps as an approach to implement complex systems by forcing the programmers to build up a solution bit at a time.

In this lab you will practice this method by solving a simple problem using the TDD method.

This lab is designed to accompany the lecture "An Introduction to TDD". The slides for this lecture are included here for reference.

Please use the comment section at the bottom to offer feedback/corrections and to ask questions after the lab session. Thank you.

Read all of these instructions before proceeding.

Set up

1. You will work in pairs. One of you will be Alice and the other will be Bob. One keyboard per pair.
2. Decide who is Alice and who is Bob.
3. Visit the cyber dojo entry page.
4. Click the start coding button, you will be presented with a minimal coding environment that you will use to complete this lab.
5. From the file list on the left-hand side select and read the instructions file. This describes the problem that you will be completing today, TDD style.
6. Click the test button. See the test failure and the red icon appear. This is not a bad thing. Embrace the red - it shows you there is work to do.

The exercise

You will be following the Test-Driven Development cycle: red, green, refactor. This lab is not about solving the problem as quickly or as elegantly as possible but rather about how to solve a problem in a step-wise fashion without introducing any incidental complexity.

1. Currently your tests are RED. Alice should fix this. Change the implementation in FizzBuzz.java in the simplest way possible to make the tests GREEN. Check you are GREEN by pressing the test button. There are some hints in the comments.
2. You are now GREEN. Alice should refactor (re-organise) the code to make it more readable. Are things named nicely? Any comments that don't make sense? Click the test button to make sure you are still GREEN. You can do this step more than once.
3. You are still GREEN. Alice should now write a new failing test in FizzBuzzTest.java. Press test. You are now RED. If Alice inadvertently wrote a test that is GREEN then she should write another that will turn you RED.
4. Pass the keyboard to Bob.
5. You are RED. Bob should fix this in FizzBuzz.java and press test to make sure that he has done so without breaking older tests.
6. You are GREEN. Bob should refactor and press test to make sure he hasn't broken something.
7. You are GREEN. Bob should write a new failing test and press test.
8. Pass the keyboard to Alice.
9. Goto 1.

Hints

• We expect to see a large number of test runs (>30) in the course of solving this problem. Hit test all the time.
• Focus on solving the core of the problem and not necessarily on how to test that you're printing numbers.
• If you finish the exercise before the end of the lab then please start a new session by revisiting the cyber dojo entry page and try the exercise again from the beginning incorporating learnings from your first attempt. Don't be tempted to take larger steps though.
• The steps we took to develop a prime number algorithm in the lecture on Monday are summarised in this gist. Use this as a guide to how small and stupid the individual steps should be.

An Introduction to TDD.pdf