Starting TDD – One Day Experiment

A repeating question I encounter a lot is how to start with practicing TDD. in fact a while back I wrote a series of post on how one can start this in various contexts
(part 1, part 2, part 3, part 4, part 5, part 6, conclusions)
some people claim that TDD is a group activity, therefore it’s a waste of effort to practice alone. I believe that TDD is a personal skill, and while its better to have the whole team doing it, it can be practiced alone. Nothing should prevent you from trying to improve the quality of your code. (and in most cases the added value will negate any delays you might experience initially).
in this post I’m offering another way to start. in fact I think that a controlled experiment might be a better way to describe this. but anyway

Practicing TDD for 1 Day

To start you should dedicate a full day for this. while I'm sure this exercise can divided into several sections, I think that to truly benefit from this (and avoid the cost of context switching) it should be done in a single day.
By the end of the day I expect you to achieve the following:

1. have a good understanding of what TDD is and what are the rules to follow
2. write some basic unit tests on a simple problem
3. write a test case for your own system
4. have a basic understanding of the tools involved in the process.

I also expect that you wont achieve the following:

1. fully appreciate the costs and benefits of doing TDD
2. understand how to apply TDD in all situation
3. Be able to write tests to all parts of your system
4. have a deep understanding of Isolation techniques

(or put simply at the end of the day you will know some of the basics, but that’s about it)

Setup

in order to complete the day you will need to download and install some tools. specifically you will need a Testing Framework and a mocking framework.

Testing framework

any framework will do, really its not that important at this stage.

• .NET use MsTest or NUnit
• Java – JUnit
• c++ – GoogleTest

Mocking framework

pick one of the power tools available:

• .NET use Typemock Isolator or JustMock
• Java – PowerMock (you’ll need either EasyMock or Mockito in addition)
• c++ – Isolator++

(some of the tools are commercial so you will need to use their trial edition which is good for a few weeks)

Learning phase

The first step is to get a basic understanding of the principles involved. for this I would recommend the following session by Uncle Bob
Attempting as it might be don’t skip this part. It takes about an hour, but the important basics are in this. In order to succeed one must know what are the rules of the game and what are the expectations. doing TDD is not just about writing tests, its about how to write code differently. And the goal is to try this different way, not just write tests.

Do a Code Kata

pick a kata from the following page, any kata will do but I would recommend going with one of the katas in the Beginner++ section.
your goal in this step is to practice TDD on the kata.
that is apply the basic rules of TDD while trying to tackle a relatively simple problem.
I would expect you to be able to go through the kata (mostly) in under an hour

Learn Isolation Principles

The next step is to get familiar with your mocking framework of choice. Most likely, the easiest way to do it would be to go the the relevant tool website and get through the “getting started” or the “Introduction” parts. The goal is to understand what are mocking framework, what they are used for, and specifically learn the API of the tools and be able to use it.
If you want to invest a little more time and learn some of the theory behind this, here’s a very nice session (hour and a half) by J.B. Rainsberger which I personally like very much.
you should end this part by doing the following:

1. Create a new project.
2. To this project add 2 classes one that you want to test (Class A) and one which is used by Class A (Class B)
3. Add a method that just throw an exception to class B and make Class A invoke that method somewhere.
4. Next write a unit test which test Class A, specifically the part should activate the code in A that invokes the prepared method on class B.
5. Use the mocking framework in order to make this unit test work/pass.

Yes this is a very simple exercise, but in order to finish it you will need to pass through all the basic steps for using the mocking framework tool.

Take a break for lunch

Tackling the real system

The last part of the day is dedicated to write some unit test on your real life system. What we want to achieve is to actually write some tests on the real system that you actually works on.
The first step is to pick a place in the system to start in. The trick here is to chose an good part that on one hand wouldn’t be the hardest most complex part, but on the other hand still would surface the real issue that will be encountered later on. The ideal place should be a place that is focused on logic. Try not to go for upper part containing any GUI sections, and also try to avoid the lowest parts dealing with the data base (if there is one). If possible try to pick a class that reside somewhere in the middle tiers. hopefully somewhere inside the business logic.
After you picked your part, locate the class you actually want to write test for. When you have it, the first step is to locate the dependencies of the class you will need to handle. Start by writing those down on a piece of paper, and then dedicate some time to figure out how they are going to be isolated. Usually what helps is answering the following questions:

1. How are the dependent instances (the one used by the class under test) get created
2. How are they get “connected” (injected)into the class under test
3. what is the expected behavior you need in your tests

answering these question will help you later on in setting up the fakes (mocks) in your test.

Write some tests

next just write a couple of things you would like to test. The key here to start simple. think of a specific behaviors you want to test. for each behavior, think what is the initial state the test should start at, what is the action you want to test, and what is the expected behavior (result) of that action (and how you clean up after the test). When you have all those just try to write the test.
And always remember to have patient.
The first test in a new system is always the hardest to write. Even an experienced TDD’er is likely to take a couple of hours to actually get some tests on a new system. For a beginner it might take longer.

Summarize the day

Last action of the day is to think and reflect on the experiment. if you followed the steps, then you should have some tests on your real system. Now it is time to reflect on those and see what else you can learn. Think on all the things you accomplished during the day. Chart down the things that you need to invest more time in. Recap the main difficulties you encountered, and most important decide upon a few key actions you would like to take in order to continue your learning.
And of course let me know how it went.


Update
It seems that the kata site went permanently down so here some links to some code katas sites:

1. http://codekata.pragprog.com/
2. http://www.codekatas.org/
3. http://katas.softwarecraftsmanship.org/
4. http://content.codersdojo.org/code-kata-catalogue/

Posted in: Agile practices,Development Practices,Self Improvment,TDD,tips