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

So how are design pattern working for you?

A confession. I never did manage to make design pattern work for me.

A disclaimer. I don’t think that this is because design patterns are in any way “wrong” or “bad”.

Yes, I do use them occasionally and Yes, I do know a fair share of them. However, I always have this nagging feeling that I should know more patterns, and at the end of the day, when I’m actually designing my systems I rarely go:

“ahmm I can use the XXXX pattern to do this”.

So why is this so? why after so many years of using design patterns talking about patterns and even arguing quite a lot about them, I still can’t make them work for me?

I wonder…

The human brain as a pattern matching machine

Start of July I attended at Vipul Kocher session during the SIGIST conference, in his session Vipul talked quite a lot about patterns and specifically about testing patterns. All and all it was a very interesting session, out of which I would like to repeat two main idea’s. First, Vipul initial claim was that our brain is basically a very sophisticated and efficient pattern matching machine. We use patterns on a daily basis. We see patterns everywhere, we recognize all kind of patterns we create new pattern, and often enough we even use Meta patterns (patterns which are used to create new patterns). No wonder our brain is such effective in matching patterns.

Learning to speak

Vipul’s second idea I would like to quote, is the fact that human apply this pattern matching ability in or language learning process.

And in the first time we are not even aware we are doing so.

When learning our native tongue, our brains learns patterns for matching single words, to match complete sentences, to match grammars rule and to match common mistakes. And it does so without us being conscious to the process.

The second time we learn a language the process is different, instead of absorbing the patterns instinctively, we apply a conscious learning technique.Instead of understanding specific word, we translate meaning from our native tongue, instead of deducting the grammar we LEARN grammars rules from books (or a teacher). This is also a way of learning. However in general the end result is inferior, usage of our native tongue will always remain easier and will always be of higher quality.

Misplaced Design Patterns

When talking about design patterns there are a couple of anti pattern I see in their usage. Again, I don’t claim there is something inherently wrong with patterns. I do see however problems with their usage. The most common issue I see, is a problem in applying patterns. Specifically, too often I see misplaced design patterns scattered around systems. Look at your current system you are developing. How many singletons do you see there? are all of them necessary? how many times you have argues with someone that while XXX is a great pattern, using it here seem to be out of place?

Initially I thought that this is caused by simple lack of pattern knowledge and understanding. However I think the reason is simpler than that. Our brain is always on the look for patterns, our thought process is rigged to order the world around us into known patterns and shapes. It does so instinctively all the time, and specifically during design it tricks us to see patterns which actually might not be there. It takes a really trained eye and conscious effort to compensate. Failure in doing so results in having a misplaced pattern in our system.

Design Pattern as a language

Haim describe in “Design Patterns and the Tower of Babel” one very important benefit of using patterns. Patterns serve as a common design language for us, and this is good.

However there is a catch. At least for me, the Design Pattern language is our second language. As a second language I will always find it harder to use. When using a secondary language (as in English ), I always struggle for the right words (patterns), I fail to understand the nuances behind them, I make stupid grammar mistakes and occasionally I use inappropriate words (if you don’t believe me read this article again). When I use Design pattern I feel the same, no matter how much effort I invested and will invest in learning patterns, I think that for me the cause is lost. I will not be able to use design pattern as my “native design tongue

So what should we do?

I see two options, the first is making sure that pattern does become the native tongue for new comers to our profession. On the upside design patterns has got a hold and I do see this more and more new comers learn them very early. However,I think that this process is going too slow. In order to actually see this done on a bigger scale, design pattern should be embedded into basic training and should be thought at universities (which I haven’t seen happening yet)

The second option is for people like me, those that will always have a different native “design tongue”. Like always, the first step is to admit that we have a problem. The problem is that the pattern language will always feel uncomfortable and be less effective for us. We still can and should use it, but when we do, we should be aware that we are “translating” and in the process our meaning can get twisted.

This is very frustrating. Especially when a “native pattern speaker“ meet a “second langue pattern speaker” like me. No matter how I try to avoid it, I end up reverting to my native language in order to “keep up” and when I do confusion start to hit (resulting occasionally in some heated arguments). Therefore the second step is to always keep in mind and be aware that this is happening.

When two “Foreign pattern speakers” meet

And last, and this is what I should always remember to verify, sometime on the other side there is another “pattern as a second language“ kind of guy. When this happen to be the case, we can sometime, just maybe, skip the whole pattern things. Chances are that it will be easier to communicate using our native design tongue.

So what are you?

1. a native design pattern speaker?
2. learnt design pattern as your second language?

Read more »

Posted in: Design,Random Thoughts

Agile Practitioner IL– First Meeting

First group meeting went great. (Here is the group forming)

Thank you all for coming and participating

Elad Sofer

which seems to be enjoying himself here, just blogged about it and I couldn’t have said it any better than myself.

I will only talk about the second part of the meeting.

During this part, we tried to get a feeling on where the group would like to take this forum/meeting/activity.

W attempted to gather some ideas on the following:

1. What content would we like to discuss
2. How we would like o conduct these sessions
3. who would we like to hear talking.

and after some discussion and debate:

Here are our main “finding”

Topics of Interest

The four winning topics are:

• Continuous Deployment
• Agile for Executive (how to convince and how to include them in the process)
• Agile in Enterprises
• How to start the development of a new product using an agile method

the runner-up topics were:

• choosing content for a sprint
• Agile in none SW development projects (support, Maintenance, IT,…)
• Scrum in details + real life experience
• dealing with the Integration phase in an Agile process.

How to conduct these meetings

About the how, the consensus was that a session which is divided into two parts in which one is a lecture and one is an activity based was great.

another idea was as follows:

• 1/3 Presentation
• 1/3 collecting ideas for discussion and choosing which ones to discuss
• 1/3 Discussions in small groups on the above

Who would we like to hear

and last on the who front we got 2 local names Roy Osherove and Oren Ellenbogen (consider yourself invited), and two international speakers: Martin Fowler, Alistair Cockburn (I wonder if we can get on of them to visit)

and just before I forget, I would like to thanks everyone who helped make this group come into life.

Especially Elad and Ilan who partnered up with me, and really did most of the work to create this group. To Ohad Israeli and Nice for hosting the event giving us their excellent facilities to conduct this meeting. and Last to Typemock who sponsored the event and made sure we wont stay hungry

Read more »

Posted in: Agile Practitioners IL

TDD .NET Course

Next month (starting on August the 8th) (Starting on August the 14th) I’ll be conducting a public “TDD .NET” course . Registration is now open for everyone, so go here and book your place.

The course TDD.NET is based on practical experience and lesson learnt gathered over the past several years. The course main goal is teach basic concepts of TDD practitioners while giving participants enough practical knowledge to start practicing on their own.

Read more »

Posted in: Course,TDD