Adopt Unit Tests First

Some ways of AdoptingXp are more effective than others. In particular, it is useful to:

Get immediate feedback that the new practice is producing better results.
Follow human nature; choose something that people like.
Choose something that has short term benefits so that people feel like they are helped by the practice.

UnitTesting typically does all of these things.

Therefore,

Adopt UnitTests first. Once people see the benefits of a simple and effective practice, they will be more willing to try out other proposed practices.

Evidence/Examples

A lot of sources claim that the first thing they tried to adopt were UnitTests. This is especially critical in order to AdoptRefactoring, since you pretty much need UnitTests in order to ReFactor effectively.

Needs to be fleshed out with examples. I think there are a lot, so I think this will soon become the first true pattern of the AdoptingXpPatternLanguage.

I haven't reached (or come close to) the adoption of XP yet, so this story probably doesn't count. But here it is, for what it's worth.

In an environment of unconscious process, I've been pitching the ideas of software development discipline, agile processes and XP with little success. The notion that we need a process has become widespread, but the upper hand is going to RationalUnifiedProcess with lots of documentation. Somehow, the 700-page document describing the requirements in imprecise language is going to be better if put in RequisitePro than in Microsoft Word. (Late news, the cost of putting Rational's tools on every developer's desk is causing some rethinking on this course.) Your company might want to SaveLotsOfMoney.

In despair at the lack of progress, I've carried on the best I can. For the past year, I decided to write all my code test-first with fine-grained unit tests. I've promoted the technique to others. Though the project leaders thought it was a good idea and, at the kick-off meeting, said to use Junit, no one else really has. (Some have written a few Junit tests to do EJB-level tests, but this still requires deployment to the J2EE server and having appropriate data in the database. The tests are not completely automated.)

I've offered to sit down and show people how to use Junit, but they didn't feel they had the time. Their development was so slow due to the time it took to test each change and debug the code, that they didn't feel they could afford to slow down and learn a new technique. In the mean time, I wrote some of the best code of my career. Often I found myself forced to architect things more flexibly than I otherwise would, just so I could write the test.

Then the crunch time came. When others were frantically working late nights to integrate all the pieces, fix bugs and accommodate late changes, I was calmly turning around new requirements in short timeframes. It gave me a lot of credibility and there's more interest in the technique now. -- GeorgeDinwiddie

However, the will to do refactoring can be used as the fuel for adopting UnitTests. But I'm still not sure if I should introduce UnitTests or ReFactoring first. UnitTests sure are easier to explain. -- AndersBengtsson

I think the danger with introducing ReFactoring first, is that people might be tempted to think they can do ReFactoring without UnitTesting and so never get in the habit. -- PhilDawes

Agreed, unit testing is likely the foundation for many xp techniques. The only real downside to them is "reduced" productivity in the short term (i.e., worst case, the same code gets written, plus some tests). But if consistently used, it provides a structure which can be leaned on reliably. --cwillu

Personally, I find that ProgrammerTests, Refactoring, and DoTheSimplestThingThatCouldPossiblyWork are so tightly coupled that it is counterproductive to try and introduce one first. TestFirstDesign works because I can quickly create a simple solution. I can only create a simple solution if I know I can come back and refactor the code. I can only safely refactor the code if I have the ProgrammerTests to verify the refactoring. Without this simple cycle: write the test, write a solution, refactor the solution, there is not a lot of benefit to any of the pieces. --WayneMack

I think that adoption for all of these methods has to come with direct benefits for the developers. Yes, your code will be better, and you will have to work shorter hours, but that is a benefit that only comes in the long term. Why do it now? That is the question that you have to answer. Problem is that there is a general assumption that people think, "if it might be better, I'll try it." All we have to do is infer it might be better. Having the example of how well it worked for you is a good starting place.

So do what works in programming. DoTheSimplestThingThatCouldPossiblyWork. Put up a board with the number of tests you have and the number of bugs. Put up information about your own velocity so other people can see it change, or go up. Show other people how easily your code integrates. See if you can talk your manager into having a 'Write the most tests' contest where if you write the most test you get the travel coffee mug. Anything to encourage people to adopt it.

I guess I am assuming somewhat that your manager is onboard with you as well, which may take additional convincing. Again, with him DoTheSimplestThingThatCouldPossiblyWork. Figure out what that one thing is and see how he or she feels about implementing it. Make it seem like their idea. Find one other person and get support to PairProgram with them. Watch the amount of work you both get done shoot up. Make that public. Then you can start pairing with people and teaching them testing, and your manager won't say a boo about it because your simply being more productive. Then the people you paired with can pair, and teach others. Small incremental changes. ---Todd Edman

AdoptingXpPatternLanguage

CategoryPattern | CategoryExtremeProgramming | CategoryAdoptingXp