The value of a 1 day introduction to TDD workshop

Next month I’ll be teaching a 1 day Introduction to TDD .NET workshop. And I was asked to explain what is the value of attending such a workshop. Clearly one can’t learn how to TDD in a single day, and indeed this is not the goal of the workshop.

So what is the value in a single day Introduction to TDD workshop?

I will let the reader judge for themselves. However here are the things I expect to cover during the day.

1. Go over the basic rules of the TDD practice
2. Explain and demonstrate what a testing framework is used for.
3. Introduce base Isolation principles.
4. Explain concrete ways for mastering the TDD skill.
5. Go over the humps of pain – i.e. the main obstacles for doing TDD
6. Let participant practice their firsts steps in a safe environment.

I expect people to come out from the workshop with the following:

1. Knowing the costs involved in TDD.
2. Understanding the benefits.
3. Know what needs to be done in order to actually learn it
4. Be aware of the main obstacles and pitfalls in the road for mastering TDD

So is all this worth a single day of your time?

if you think it is you can Register Here

Read more »

Posted in: Course,TDD

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/

Read more »

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

Agile Planning is just Enough

Actually Agile planning is based upon two main principles:

• Just enough
• Just in time

that is, at each stage we plan just enough to get us going and answer the important questions at that stage and than we stop.

In this post Gil talks about agile planning how it mainly focused on short term. Well Gil you missed some important staff about what you call Agile planning.

lets start by saying that talking about agile planning as a concrete thing is basically misleading, agile planning is just a set of very basic principles (which I tried summarizing above). One need to refer to concrete planning practices in order to udge them.Planning is scrum does not look like planning in Kanban which does not look like planning in XP…

The example used is taken from a medical field, in which the stake holders

“needed to know everything would be ready in time, three years in advance.”.

Well sorry there is no such magic in our field. NO one can know what will happen three years in advance.

when you claim to be able to do that you are simply lying, both to your sponsor and probably to yourself as well. You can estimate, you can guess or you can extrapolate based on prior knowledge.

you will never KNOW.

Even when you sign a contract with millions of dollars in fines for being late, you cant know. you are just doing an educated guessing taking all the buffers and safeties you need in order to hopefully meet you goals in the given time. And BTW in most case you don’t (just check out Chaos report if you don’t believe me)

Long Term Planning

Gil is right about one important thing, almost every project need a long term plan. Question is and always will be is just how long do we need our plan and how detailed do we need it to be.

In scrum for example, there are 3 levels of planning:

1. the daily planning (done in each daily meeting) – we plan in extreme details what will be done in the next day
2. the sprint planning – we plan in details which tasks will be done during a sprint ( a few week ahead)
3. the Release planning – we plan the list of stories which we will deliver in the next release (typically 3-6 months)

And here Scrum stops.

That doesn’t mean there are no longer term planning, just that the longer term is “out of scope” for the basic Scrum process. u will still need a product roadmap, you will still need a strategic planning. and maybe just maybe (like in the example Gil gave) you will need to give a list of expected features for the next “big” version. However this kind of planning will always be more vague, will deal in general capabilities we would like our product to have and at the end will always be open to interpretation. it would never be concrete enough to actually start working on.

The nice thing that at the end my recommendations and Gil are the same (well we do basically believe in the same things):

do a release plan (3-6 months ahead) make sure you are working on the highest priority features and make your best to develop them as fast as you can, and always keep your progress visible top your customer.

So lets do a reality check, planning is nice and important, but “responding to change over following a plan” is what makes agile processes works. The longer the time frame you are planning chances are higher that this change will be bigger and come sooner.

Read more »

Posted in: Planning,Scrum