Must programmers know how to Test?

I was never asked before if a programmer should know how to test. The underlying assumption is that programmers know hoe to test their own work, and therefore are skilled at testing. Problem is that they are not. And the sad thing is that so far they have managed to get away with it. I’ve been a professional programmer(that is writing code for a living) for more than 10 years, in all the places I’ve worked my managers did ask me if I tested my work. And my answer was always “of course”.  But never was I actually challenged on that. No matter how many bugs were found in my code, no matter how much empirical proof there was that I did a bad job at testing. None of my technical managers ever told me, “please take this work back and test it again, and this time for real”, ever. And never have I seen it happen to any of the other programmer I worked with. I did get work back from time to time with claims that some of the functionality was missing, I did get a lot of bugs to fix. At times it was so bad that my “testing” activity usually only included making sure it compiled executed and didn’t crash on my machine. and that what I called testing.

Programmer who Cant test will become obsolete

As automation gains more hold in our industry people start to expect much more from testing at the unit level. In my last work place doing test reviews was part of our on going process, in fact we probably invested more time in reviewing test code than actual production code. For us it was extremely important to make sure that written code was properly tested (verified) at the unit test level. I expect this is very common to all software teams doing TDD. And while I’m sure many of us just wait  for this weird TDD notion to go away. its my strong believe that it wont. on the contrary latest surveys suggest that as agile is gaining in our industry the necessary engineering practices are also

Programmer – catch up on your testing skills

if you as a programmer want to stay relevant in future markets, you should really start increasing their testing skills. Yes there is still time before testing skill will be listed as one of the mandatory skills in job posting. The growing need for writing automation at all levels, gives a definite advantage (at least in my book) to programmer that has some sort of formal knowledge or experience in testing. (and yes I will need to see some actual proof and will verify such claims during interviews). No I don’t think a programmer should be a professional tester as well (although that might help), but basic concepts of QA, properly designing test suites and understanding that there are more than just unit testing is something I would expect every self respecting programmer to know. In  my limited experience I have found that programmers that posses this knowledge and skills are just better programmers.
And if you want to know how to start here’s something you can try: STARTING TDD – ONE DAY EXPERIMENT

Bottom line

As a programmer you should want to know how to properly test your work(at least at the unit level) ,in order to decrease the time you will be looking for a new job

Read more »

Posted in: Agile practices,ATDD,Random Thoughts,TDD

Why should you Learn TDD

One word:

I believe that a developer work should be one filled with the joy of creation. When I started out to become a programmer I thought that it would be great. my work will be filled with:

• Joy of creation when working on building a solution to other people problems
• moments of joy when completing new things and releasing them to the market
• moments of satisfaction from work well done
• moments of eureka when I find great solution to difficult problems
• moments of collaboration when I work with my team members to achieve a shared goal

a few years later I found out that:

• its not fun when you finally get your product to the market realizing you just solved the wrong problem
• Its annoying that whatever you are doing always seems to take longer then expected
• its frustrating when you never have enough time to actually complete your work as it should be done
• its not easy to work along other people which are stressed out just like you.
• its disappointing that you never get a chance to learn something new because now is not the right time and we first need to finish.
• its depressing to continuously get a stream of defects on the code you write
• its terrible to work 3 days straight to understand why the system keeps on crashing at your client, when it behaves perfectly ok in your own environment
• its frightening to work on unknown parts of the system not knowing if what you will do will only cause more bugs

So why should you learn TDD?

Because TDD is one major step towards bringing the joy back to work:

If you do TDD right, many of the stupid defects will go away.

if you do TDD right, your system design will improve making it easier and faster to change

if you do TDD right, you will have a safety net guarding you from mistakes.

and if you do TDD right, you may be able to bring some of the joy back to your work.

Read more »

Posted in: Engineering Practices,TDD

And Sometimes You Lose

Here’s a story of TDD adoption failure:


about Two years of effort becoming insignificant in about 6 months.
Shame

Want to adopt Agile and don’t know where to start?
click here to learn

Read more »

Posted in: TDD

Tests Not Run Waste Away

Over the last couple of weeks I was helping a developer tackle some nasty issues with some automated tests which kept failing for no apparent reason. The tests in question were not unit tests and did not belong to the end to end type. Instead they were somewhere on the level of component and involved several units of code, a service or two, some threading and communicating to another process.
After watching the struggle continue for a couple of hours, I started to get the “writing tests shouldn’t be that hard” alarm buzzing. So I took a step back realigned my thinking glasses (yes I think using my eyes) and looked closely again. What I now saw was:

1. The amount of time we invest on this might indicate a negative ROI
2. The heavy usage of mocking framework was completely taken to the extreme to a place in which no mocking framework should be.
3. The tests were somewhat in the middle and looked like an hybrid creature. On what end they looked and smelled like focused unit tests when in fact they were integrated tests.

At that point I decided to take it up with the powers in charge and ask the bigger question of what exactly are we doing wrong here. maybe we are investing the effort in the wrong place using the wrong technique.
Today I met with the power to be and I got to hear the complete story. As it happens these tests were actually quite old and were initially written quite early when the team was just starting. For one reason or another the group of test were tagged with the Ignore attribute causing them to be excluded from the test execution. Since then they realized that they were going the wrong way with those tests, readjusted their method and actually what they have now is proving to be quite effective. The poor developer I worked with was the one who draw the short straw on fixing these old tests and bringing them up to date. The problem is that the ignore thing has gone undetected for some quite time.
So what can we learn from this:
If you invest the time to write the test you should take the effort and execute them.
Tests which are not worth executing have no reason to take up source control space. They should just be deleted. (In our case writing the tests altogether was faster then fixing them – which you always find out to be the case after you finish doing both)
Like production code tests should be maintained. The moment you stop doing so they starts to rot away and the effort involved in fixing them seem to be growing on an exponential curve.

The title of the post was taken from the “Way of Testivus”. I’ll be talking more about these things in the next IDNDUG meeting and more specifically in the upcoming SIGIST conference

Want to adopt Agile and don’t know where to start?
click here to learn

Read more »

Posted in: AUT,TDD,tips

Israel Dot NET Developers User Group (IDNDUG)

Next week I’ll be talking at the IDNDUG group meeting about test automation. its going to be quite a long session (about 2 – 2.5 hours) and I will try cover several aspects of test first approaches as they developed over the past few years.
While the session will not be completely technical and will I include some general background, I do intend to dive a little deeper then your regular “Introduction is TDD” session. so if you are planning to come do bring your laptop, we might find some use for it.
for more details and for registration go here

Want to adopt Agile and don’t know where to start?
click here to learn

Read more »

Posted in: ATDD,AUT,Events,TDD

TDD exercise for beginners

Two years ago I posted about this excellent site that contains various TDD problems that can be used by beginners to practice their TDD skills.
Over the last couple of days at the TDD mailing list there’s a thread in which people are putting links to all sorts of great resources for such exercises so I thought to put them all in one places for future reference

1. Http://nimblepros.com/resources – a site containing 11 code katas. I actually participated in a testing dojo that used the Gilded Rose Refactoring kata and it was great
2. http://stackoverflow.com/questions/2443697/tdd-exercise-ideas -  a thread discussing the same subject with several problems for TDD.
3. http://codingdojo.org/cgi-bin/wiki.pl?KataCatalogue – another (the original?) Kata catalogue. contains all the classics and then some
4. Roy Osherove blog contains two katas the first has variants in almost every language out there, and the second is a little more advanced aimed to teach interaction testing
5. http://cyber-dojo.com/ – when pushing the setup button you get a nice list of various problems.
6. http://coderetreat.org/gol – the classical Conway’s game of life used in Code Retreats

If you know of more sites and resources please write them down at the comments below

Read more »

Posted in: Agile practices,TDD,Unit Tests

“I have a Legacy System” is a lame excuse

Q: “why have you not written any automated unit test until now?”
A: “ look, we have a and complex big system. no one has written automated tests for it. it will take me too long to do it just now. I know its important but we have XXXXXXX so we cant do it now”
This kind of excuse, which sadly I hear way too often,  rate high among the “list of most lamest excuses”.
Don’t believe me?
How about this?
Q: “when are you going to cut down on your expanses and start saving money?”
A: “Look, I’ve already have a big mortgage on my house, and the cost of living has risen lately. So now is definitely not a good time to start saving. In fact since I just need to replace my car with a new one I’m just on my way to the bank to get an additional loan.”
or maybe this?
Q: “you know that you were diagnosed with high cholesterol, when are you going to start a healthy diet?”
A: ”you know you are right. But we are just entering the holiday season so now is not a very good time to start. In fact I cant wait for the family dinners, Health is not high on my family priorities, I’m guessing that’s why its so good”.
and this?
Q: “why aren’t you using a source control system?”
A: “well we have this big batch of code and its kind of a big mess. We thought about starting to use a source control, but it will take us too long to port our code into such a tool, and train all the developers. And you know we need to do XXXXXXX, so now is not really a good time”
Its Never too early to start
I think you got the point.
It all boils down to accumulating debt, technical debt in case of software development. That is,  you know you need to do something now. ASAP! But since  the effort involved seems to be high, you delay. You decide to take on additional debt, and with it comes additional interest. Causing you to do more rework and have less time and the monster feeds itself.
Face it, like most necessities in life there will never be the perfect time to do it. Test automation on all levels (unit,integration acceptance E2E,…) is not an option.  More and more teams realize that and do something about it. To stay competitive you will have to do it also, later will only make it harder. 
The fact that your system is big and complex is the real problem, Test Automation is one proven way to tackle that problem.

Read more »

Posted in: AUT,Development Practices,TDD

TDD for Legacy Systems

We know test automation is crucial probably even mandatory, and TDD is a great practice to use, but lets face it our existing system is not test friendly to say the least.
so now what?
TDD for Legacy system is  my way to help people tackle this problem. During this two day training we will learn how to cope with existing systems. We will go over the basics of Test First methodologies and learn how to turn a system from a big  chunk of legacy code, into something that is covered by a suite of automated tests. we will discuss issues of setting up a continuous integration server, different type of testing that can be applied, how to tackle existing system design and how to slowly but surely improve our code base while writing automated tests for the existing code.
the training will assume no previous knowledge of test automation, however it is  hands on and does require previous experience in programming (at least one year on a real live system).
if you are interested and want to learn more details about the course syllabus and content can be found here
and of course you can just register here
so don’t wait up, take you r first step and come learn about modern software development.

Read more »

Posted in: ATDD,Course,TDD

Bug: $10, Future Bug: $200, Angry clients: $5,000, One TDD course: Priceless

When you write code for a living, mistakes can be expensive. They can create bugs that will crop up in the next version or the version after that, they can cause problems down the line for the end user who can't use the software and worst of all, they can create bugs that you spend longs days (and nights) working to find before the release.

One way of avoiding these mistakes is Test Driven Design - write the test before the code and the bug (if any) is easy to find. And a course in Test Driven Design is not that expensive - and even less so today :)

http://goo.gl/3VMqM

Read more »

Posted in: Course,TDD

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

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

TDD .NET Course

Next Month I'll be giving a 3-day course in TDD. The course will take start on the 12/7 and take place at Sela house. If you want to join or know people who might be interested, just leave me a comment. More details about what will be covered you can refer to the course syllabus here

Read more »

Posted in: Course,TDD

Starting TDD – Conclusion

How do I start TDD? is a question I’ve been asked too many times. Unlike many I don’t believe that in order to start you need the entire team approval. In this series I’ve described a few situation one might find himself in and offered some ideas on how to approach them. Although each developer has its own context i hope you can find some resemblance in the described cases and find the ideas useful. Since this is what I’m doing for a living this days, I would love to hear about your way on the TDD road and specifically on how you started and what were the initial experience.

last in a previous post i was asked by Daniel the following:

So if a single developer on a team is driving the design of his code by TDD, do you really think it would work? The code is probably going to be different in design hence other will probably have problems reading it since it could be a bit of paradigm shift. Also, if the TDD-developer has a similar skill-level as the rest of the members, the implementation time of each future will probably be longer for his items, even if the total time including corrections after QA-people, do you really think things like this will go unnoticed?

Daniel, I don’t know if it will work for you, but i have seen it to work several times. The differences in designs does tend to invoke a design discussion, which i have found to be a good discussion in which testable design is always defendable,in fact I encourage this discussion since they are a tool for winning people over. regarding your second question, I think that a reasonable developer (in many scenarios) can make the overhead nearly unseen, and i would also expect that it wont take too long for that developer skills to rise over his fellows programmers. However, I’m a believer of honesty and visibility, I wouldn’t try to hide what I was doing from anyone, and when challenged I would answer that this is the way i know how to code and point to the low defect rate resulting from doing things this way.

Read more »

Posted in: Agile practices,Development Practices,TDD

Starting TDD (Part 6)

if you are really lucky you will find yourself joining an team which already practice TDD:

New developer joining a team doing TDD

You are just starting a new job (maybe in a new company). You have heard all about how the team is doing Agile (Scrum/XP) and how the tests are written before the code (TDD). In fact you are nervously waiting to start doing all those wonderful things.

Take a breath.

Joining such a team is not an easy switch. If this is your first time doing TDD (and Agile). It is going to be kind of a shock, working in an agile team is different in many aspects TDD is just one of them. It can take some time to make the needed adjustment. I myself have not fully experienced this, but helping other pass through the transition, I have learned that it can be a frustrating process, especially if you not a new developer.

The best way to speed the process is to make sure to pair a lot, i.e., Don’t work alone! Always ask to work along with somebody else on the team. Even if the team is not practicing pair programming on a usual base, insist that for your initial phases you would like to sit with others and learn how to do things properly. Pairing is a great way to get the needed knowledge and expertise (and the fastest way I know of).

Read more »

Posted in: Agile practices,Development Practices,TDD

Starting TDD (Part 5)

With some luck, one day, the place you are working in will decide it want to fully adopt TDD. On that day you might find yourself in the following scenario:

A lone developer in charge of implementing TDD

The team/ manager have considered TDD, they chose to evaluate it and decided that its a good idea. the decision as made and in fact most of the team is quite happy with the change. However, since its a busy time they want to approach the subject with some care and have chosen you to start the ball rolling. that is you are expected to lead the transition for your team first by doing it yourself and then by helping the rest adopt the methodology.

The steps in this scenario are very similar to the one described in Part 4 the focus however is to gather as much real hands experience the fastest way possible.

Sometime this kind of experience can be bought. If possible, bring in an outside consultant that will help you in the transition. If not, try to to make sure the next hire has hands on experience.

if this options are not present, arrange for the whole team to attend some relevant gathering/conventions. Go with the team to TDD courses. and in any-case, when following the steps described in part 4 make sure to share and include other team members in the process. And last practice a lot of pair programming TDD session.

remember the idea is to share and include the rest of the teams even if they are not actively practicing TDD yet. A successful TDD adoption is much a matter of mode and spirit, not only a technical problem.

But always remember, The key factor is to gather as much hands on experience as possible and having the patience to build upon such expereince.

Read more »

Posted in: Agile practices,Development Practices,TDD

Starting TDD (Part 4)

In some cases the idea of TDD is seen as a promising idea by the organization. lets consider the following

A Lone Developer in charge of evaluating TDD

You talked with your manager and thinks TDD might be a very good idea. in fact he has given you a green light to evaluate the approach. most likely other team members are also in favor of checking this out all are waiting for your conclusions.

In this context the plan of action is very similar to the previous scenario. The difference here is that you are expected to do a more thorough job, and you are expected to show result in a given timeframe.

Therefore, you still need to pass the learning phase, you also need to setup a CI Server and pick out the tools before starting. Time boxing the learning phase will be a good idea, while you still need to gain the knowledge you would like to do it as fast as possible, so pick the training solution that work fastest for you (for many a TDD course does a decent job in a short timeframe). On the other side you would like to invest more time in comparing and evaluating several options for your tool set (which include the CI product). at the end you will be find it easier to justify your choices if you can show that alternatives were considered.

Next step, is picking out a good place to start the actual writing. Since you are evaluating the approach, you probably have the option of picking out where you want to start, and the idea is to pick (for the first experiments) a place that you feel comfortable working on. a Place which will not be too hard. Try locating a small, decoupled section that is logic oriented. At this stage don’t try to tackle the most difficult place, there will be time for that as well. First gain some hands on experience with TDD.

Like initial stages, you would like to time box this first effort. When you finish it don’t forget to share your finding (and your difficulties). sharing along the way will help you when you finish the evaluation and a decision will need to be made.

According to the time allocated, you might have a chance to tackle a “tougher” piece with unit tests. If you are working on a legacy system now will be a good idea to approach the issues such a system present. You will need to gain more knowledge on refactoring and reading Michael Feathers book is also a very good idea at this point. Going through legacy code is harder and takes time. The trick to success with TDD is to have plenty of patience, this will become evident when working on legacy code. Getting help is also a good idea. If possible try using other team members via pairing sessions. Paring on the harder challenges is a great experience by itself and will also make the time for resolving the issues shorter. As a side effect you also introduce TDD to other in your team.

at the end always remember that you have a specific goal, to understand why TDD will be good for you and your team. And to show how it can be adopted by the rest of the team. So don’t wait for the time to end always remember to reflect on what the experience has thought you what were the benefits and what are the challenges. during the evaluation communicate with the rest of the team and draw them into the discussion. at the end you will probably need their weight to make the organization commit to TDD.

Read more »

Posted in: Agile practices,Development Practices,TDD

Starting TDD (Part 3)

In the previous post I’ve talked how a even in the most hostile environment one can do things that will help on the road for becoming a better programmer. fortunately however the scenario described in the previous post is quite rare and in most cases things are not as bad.

The following is probably a more reasonable scenario

A lone Developer in an indifferent organization

You discussed TDD with your boss and while he is not against it, he doesn’t see enough value in it . Most likely his reaction went along the lines of:

Yes, automated unit tests are great but …

On the other side, you generally get enough freedom as long as you get the job done. other team members also think TDD an interesting concept, but again no one has yet made any move.

Start Learning

If you find yourself in this situation (which I believe is quite common), there’s much you can do. As always you start out by learning. Books, blogs, lectures, videos,.. anything will do. There is even a slight chance you can persuade your company to spend some money and sent you to an actual TDD course.

Setting up a CI server

Next step is setting up of a Continuous Integration server. Yes, I’m serious. If you are going to practice TDD, you should have a full blown CI server at your disposal. Setting one up takes somewhere between 30 minutes to a few hours. The benefits are huge, and down the line it will definitely help you convince others (most managers just love the visibility given by a CI server)

BTW You don’t need a dedicated machine for this. If you can’t locate a spare machine (and any machine will do) just set it up on your own personal development station.

Picking out the toolset

Next step will be to pick up the actual toolset for TDD. the most important thing about it is not to let this slow you done. While there are several options out there for every technology, for the most part the differences between the tools will have no affect at this point. Later on you might want to change the tools but even if that happens the actual cost of switching is usually minimal, and you will have much better understanding then. Just pick the tools you feel will be the fastest to learn. Don’t let the tools get in the way.

Practice TDD.

Now comes the fun part. Just start doing TDD. Pick up you next programming task and allocate some time for doing it the TDD way. If possible try to pick a standalone piece of code if not never mind. Don’t worry about doing mistakes. Don’t worry if your tests doesn’t seem like unit tests at all, and don’t worry if your are not following the TDD rules by the letter. You are just learning. And remember, in most cases it can take a couple of hours, maybe even half a day to write the first test. Things will become easier as you gather more practice.

You are not alone

Starting out TDD is hard. Without help it’s even harder. The fact that you are alone in your organization doing TDD doesn’t mean you shouldn’t have any. Reach out to the mailing lists. Luckily The web is filled with very nice people which likes to help. It might take some time but you will get the answers you need. The real trick for succeeding in TDD is just to have patience. It take some time to master a new skill.

Share you accomplishment

Hopefully after a few weeks/months you will be able to demonstrate the real benefits of TDD. If you stick to doing it, you will overcome the initial issues and will prepare the ground for the team to follow. You will have real experience, and it will be much easier to convince others of the value in TDD.

But even if not, if you got to this point you already are a better programmer.

Read more »

Posted in: Agile practices,Development Practices,TDD

Starting TDD (Part 2)

In my previous post I explained that you don’t need the entire team in order to start TDD. So lets see some options for the lone programmer.

The question of where to start depends upon the context you find yourself in. For example lets consider the following:

A lone programmer in a hostile organization

You are a team member (or a team lead), you tried running TDD through the team but they feel its stupid, in fact they are strongly against it. If that’s not enough your manager also think TDD is a total waste of time and is closely monitoring to make sure you are focusing on writing production code only. And the worst thing is that the organization is a strict one, no tool can be used without going through the proper channels.

Yes this is as worst as it can get and there is not much you can do (other then maybe start refreshing your CV). But still you can start with the learning parts. TDD takes some knowledge to do properly, its not enough to just decide and jump ahead. there are practices to follow tools to be learned and techniques to be adopted. I have never encountered an organization that will block a determined programmer from acquiring knowledge, even if that knowledge is not directly related to current work.

Here are some places when TDD knowledge can be gathered:

Books:

1. The Art Of Unit Testing - Roy Osherove.
2. Test Driven Development: By Example – Kent Beck.
3. Working Effectively with Legacy Code – Michael Feathers.
4. Clean Code: A Handbook of Agile Software Craftsmanship – Robert C. Martin.

Mailing Lists:

1. TDD on Yahoo Groups
2. Extreme Programming on yahoo

Also there are numerous conventions and blogs dealing with TDD and other Agile Aspects. which deals with various aspects of agile development and some are even more specific to talking and helping with Conventions (and recording of)

It might also be a good idea to refresh on proper design principle and refactoring techniques as well. Even if you wont be able to practice TDD writing clean properly design code is always a good idea and i have yet to meet someone which object to that.

Read more »

Posted in: Agile practices,Development Practices,TDD

Starting TDD (part 1)

One of the most common question I encounter is how to start with TDD. Usually the questions is formed as how do I get my team to pick up TDD.

There are many answers to this, and in fact it really depends on the specific context (more on this later) but one thing I do know.

You don’t need the entire team

A popular mistake is to think that a lone developer can’t do TDD and you need entire team do it together. This contradict the fact that TDD is a solitary practice i.e. you can do it all by yourself. Think about it, don’t you write code alone? TDD is a development methodology, its an exercise in producing high quality code, in that aspect its not different then doing low level design or writing clean code.

Do you need the rest of your team to design properly in order to produce good design (of your parts)?

Naturally the effect a single developer has is limited and will probably won’t go beyond his code, however doing TDD even if done alone will allow for his code to be better (and most likely faster). Of course its better to have the entire team do TDD. It’s usually easier and will increase quality of the entire product, but there is no reason to wait for everyone to realize that, is there?

So where to we start?

like always the answer is, “It depends…"

but more on this later

Read more »

Posted in: Agile practices,Development Practices,TDD