I am writing this post on behalf my friend He does not write anything by himself but many of his thoughts are very accurate and meaningful – I decided to share it with you.

So if you are intrested on Test Driven Development, go on…

Many people who are just starting with TDD (like me ) see it as useless, faddy term. Many of them do not see a benefit of unit testing and cannot imagine wasting time for writing tests. Many of them write unit tests after finishing main implementation, which in my opinion, is even worse.

I would like to describe a Test Driven Development as simply as possible

Imagine that you want to build a house from scratch. But we must do one important assumption – we can rebuild it any time we want, just like it was built from Lego blocks

In a traditional approach we would:

• Prepare documents, make a project, plan every room, door, windows etc. Garage is also in the plans, yes we must have a garage
• OK, walls are standing, floors are ready.
• We apparently realized that a bed is little bit too long but it was so cool that we could not miss the chance to buy it We must live with that, or rebuild the room completely.
• It would be good to have some water – of course, we have got many pipes, it should work
• Ooops, It would be better to have a sink on the other side of a kitchen, your wife decided that it would be nicer to have it by a window. Well, we can do that…
• Redesigning and rebuilding pipes in a kitchen takes a few weeks, your wife seems to be happy
• You’re exhausted but happy that wife will have easier life in the kitchen
• Suddenly your wife says: “You know… that previous design was better, now I must walk twice to take all pots and pans”
• Ooops, you set your teeth and start rebuilding a kitchen once more
• you almost finished… but wait, the garage Yes, we must have the garage.
• after 2 weeks there is a garage with shiny roof Brilliant, but we do not have a car :/ Ehh, it does not matter, we will buy it for sure next year.
• … after several months of building (and rebuilding) you finally got a house and it seems to be very nice from the outside. You have plenty features like fancy slates or a garage (but you do not have a car )

As we can see you spent 70% of your time on rebuilding and making workarounds, you’re still not sure whether your pipe redesigning broke something else in the bathroom. You can only test it by turning on the faucet and praying that it will not blow After a year of living you decide to buy a car – great big van on a promotion. But wait, your garage is too small, it was designed for housing tiny little sport car

Let’s see how it would like with TDD approach:

• You do not prepare unnecesary documents and do not plan every detail. Just enough to start.
• You want to sleep somwhere, huh? OK, let’s put a bed in the center of the field
• It would be nice to have walls and a ceiling. But wait, we should try it and then build.
• Then, mock walls and ceiling because we do not need them to test if a bed is comfortable Give them order to return 2 windows and door.
• Is it comfortable to sleep there? No? OK, add another window to the mock
• Perfect, build the room and move on to the kitchen…
• … wait, there’s no kitchen yet. No problem, build it next to a bedroom. Actually, you can build it wherever you want. You can always move it later.
• mock a kitchen with pipes, so your wife could test whether a sink will fit her needs. You can also make a stub of ICorridor with WalkMe() method.
• do some tests and check whether it will work or not.
• Check the case when WalkMe() returns 15 steps, is it enough? No? OK, do a test when a corridor.WalkMe() returns only 3 steps.
• if it still does not work, prepare some other test cases and refactor your kitchen just enough to fulfill every indulge of your wife
• when everything seems to be fitting, your wife is happy and a corridor is long enough, leave the kitchen
• as you can see, every change is quick and eventual alterations are not time-consuming
• after several months of building (and rebuilding) you finally got a house. You spent one month longer on testing, your house seems to be very nice from the outside… and you’re sure that all of your needs are fulfilled. No bloats, no unnecessary features.

The result is pretty much the same as if you were built it with traditional approach. However there are several tiny differences that diametrically change your house as a whole:

1. No unnecessary features. You avoided unnecessary garage, but you were able to test several pipe designs instead.
2. You ARE SURE that every need is fulfilled and every feature in your house just work.
3. Finally, you are PRETTY SURE that any modifications in the future can be applied without fear.

I do not have much experience in XP programming, TDD and any other light approaches. However, I have much experience with legacy and bloated code. I have also much experience with undetermined clients. It was very easy to see the difference between traditional approach and test driven development. If you have some time to try TDD, I encounter you to do it