Object Mentor Blog: TDD Triage

TDD Triage

Uncle Bob — Thu, 08 Oct 2009 09:52:41 -0500

With all controversy that has been generated buy my last two blogs (1, 2), I thought it would be wise to talk bout where TDD works and where it doesn’t

Is TDD a replacement for architecture?

No, of course not. The notion that you can generate a viable architecture by starting with a blank screen and then writing one test case after the other is sheer folderol. There are decisions that you need to make that have nothing to do with tests.

Of course many of these decisions can, and should, be deferred for as long as possible. For example, the database schema is something that can likely wait for quite a long time. The decision to use Spring, JSF, Hibernate, JPA, etc. can also likely wait. The beauty of business rules is that they can, and should, be implemented independently of database and GUI models.

In FitNesse, we deferred the database decision as long as possible. In the end we deferred it indefinitely and used flat files instead. At the beginning we did not think flat files would be the solution, we thought we’d be using mysql. But we kept on postponing that decision, and making our test cases pass. Finally, one of the stubs we’d been using to save fitnesse pages into flat files proved to be good enough.

Interestingly enough, one year later a user of FitNesse needed it to use mysql (because of corporate bureaucracy). It took him a day to make the changes. The architecture of FitNesse was so flexible, because of all the tests and stubbing, that shimming mysql in at the very end was trivial.

On the other hand, some architectural decisions need to be made early. For example you really do need to choose your programming language pretty early on. You also probably need to know whether you will be working in a web (batch) environment, or using a more intimate user interface. If you are in an enterprise environment, you’ll need to understand the existing database and plan how you will isolate your application from it.

When we started FitNesse, we made a very early architectural decision that has had a profound impact on the structure of the system. That decision was named “Download and go.” Before the first line of code was written we decided that FitNesse should not be bound to any other independent system, that you should be able to download it, and then execute it with a single command. In 2001 this meant we had to write our own web server…

Here’s the bottom line. You cannot derive a complete architecture with TDD. TDD can inform some of your architectural decisions, but you cannot begin a project without an architectural vision. So some up front architecture is necessary. One of the most important up front architectural activities is deciding which architectural elements can be deferred and which cannot.

Is TDD a replacement for design?

No. You still need all your design skills. You still need to know design principles, and design patterns. You should know UML. And, yes, you should create lightweight models of your proposed software designs.

TDD’s role is to inform your design decisions, not to replace them. The Bowling Game Kata is an example of how TDD can utterly invalidate early design decisions; but the Bowling Game is an extreme case. Usually TDD works to validate, and/or augment your design decisions.

A team of developers needs to have a design vision that they have agreed upon. This vision can often be gained with a relatively short design session at the beginning of each iteration. UML models can be proposed and negotiated on a white board. This gives everyone the context required to make progress without stepping all over each other.

However, the models should not be considered law. They are nothing more than an initial rough draft of the design. As the teams practice TDD, they will undoubtedly discover weaknesses in the designs, and uncover better solutions. These improvements should be quickly communicated to the rest of the team.

The bottom line is that TDD is a_ design technique but should not be the _sole design technique. All the old design rules and skills still apply; and TDD is a powerful way to inform and augment them.

Should TDD be used for every line of code?

No. There is a set of problems for which TDD is not particularly helpful. GUIs are an example.

In FitNesse, for example, we use Velocity templates to create our web pages. There is a lot of coding that goes into a Velocity template. But to use TDD for those templates would be absurd. The problem is that I’m not at all sure what I want a page to look like. I need the freedom to fiddle around with the formatting and the structure until everything is just the way I want it. Trying to do that fiddling with TDD is futile. Once I have the page the way I like it, then I’ll write some tests that make sure the templates work as written.

Of course it’s not just GUIs. It is the notion of fiddling that is the key. If you must massage the code into place. If you must fiddle with some aspect in order to please the customer. If there is some uncertainty that can only be resolved by a very rapid cycle of edit-and-run, then TDD is likely to be more of a hindrance than a help.

As another example, I once worked with a trading company that had to parse incoming streams of trading data. These streams did not have a well defined format. The teams had to fiddle with regular expressions and parsers in order to get the decoding just right. TDDing this would not have been wise. Writing the tests afterwards was imperative.

The trick to manage this is intense decoupling. You want to make sure you identify every bit of the code that does not need to be fiddled, and separate that code into modules that you can write with TDD. Make sure that the fiddled code is isolated and kept to a bare minimum.

For example, the Velocity templates in FitNesse draw their data from data structures that are built by the business rule processes (we call them Responders). I relentlessly use TDD to make sure those data structures are right. So when I fiddle with the templates, at least I’m not fiddling with the code that generates the data for those templates.

NOTE! Just because GUIs need to be fiddled with, does not mean that most of the code around the GUI should not be TDD’d. In fact, most of that code should be TDD’d. It’s just the tiny thin veneer of code that controls the format that needs to be fiddled. All code that can and should be TDD’d should be decoupled from that veneer. So, decouple, decouple, decouple, and then finally fiddle.

Well, if you are going to write some tests afterwards, why not write all tests afterwards?

Well, first, there’s the George-Williams study, which showed that teams who are instructed to write tests afterwards, don’t write tests at all. Of course this is human nature. Once you have the code “working” why write tests? Writing tests for code that you believe works feels like a waste of time.

But that can be countered with sheer discipline. The real reason to follow The Three Laws of TDD and write your tests first is that it greatly enhances the chances that every line and every decision is tested.

Code coverage is a sneaky metric. It is quite possible to create extremely high levels of coverage without a single assert. I don’t need to tell you that coverage without asserts is less than meaningful. When you write tests first, your assertion coverage is very high. When you write tests after, you assertion coverage simply cannot be that high. Even the most dedicated and determined developer will make some coding decisions that block later testability. When you write the tests first, this simply cannot happen. When you write the tests first every coding decision you make must support testability.

Clearly writing the tests first forces an extremely high degree of compatibility between the tests and the code. Writing the tests first also means that your first thoughts about the code are from the point of view of a user, not an author; and that also has benefits.

So, all else being equal, test-first is clearly better than test-after.

Given that we accept the need for tests, why the resistance to test-first?

Honestly, I don’t know. Clearly it can’t be a productivity issue since we are going to write the tests anyway.

Perhaps some people don’t like the fact that writing tests first interrupts the flow. It’s true, when you write tests first, you cannot write a whole algorithm. You have to assemble that algorithm bit by bit as you add one test case after another. Maybe some people just don’t feel comfortable working this way. Personally, I find working this way to be highly beneficial. It’s a way for me to think critically about the code I am writing. But I accept that some folks may find it difficult.

I once worked with an assembly language programmer who simply could not understand pointers. No matter how hard I tried to explain them, he simply could not grasp the concept. This made it hard for him to write certain kinds of programs. I fear that the folks who cannot train their brains to think in a test-first way are working at a similar kind of disadvantage, though not nearly so severe.

Wouldn’t it be faster without such high test coverage?

I’ll paraphrase Kent Beck once again. “If I don’t need to make it work, I can go a lot faster.”

I once consulted for a team that followed this rule. For them, the definition of “Done” was “checked in”. If the checked in code had bugs, then fixing those bugs went on a different schedule. Eventually the team started checking in empty source files in order to be “done” on time.

But let’s take the original question seriously. Do we really need to have close to 100% automated test coverage? Doesn’t the insistence on such a high level of coverage slow the development team down?

In a legacy environment it certainly does. Indeed, in a legacy environment I would not insist on high test coverage at first. I’d set the goal pretty low, and then gradually ramp it up over a period of months to years.

Legacy code (defined by Michael Feathers as: code without tests) is a big problem. Getting that code under automated test is a difficult and long-term activity. The pay-off is huge, but you can’t get there quickly.

In a non-legacy environment, and for all new code within a legacy environment the situation is different. High coverage with automated tests speeds you up; and it speeds you up a lot.

The reason isn’t difficult to understand. Firstly, you don’t do much debugging. How could you if you have tested virtually every line of code? My own experience with debug time is that it all but disappears. In the last year of intense development effort on FitNesse I have spent almost no time debugging. If I had to quantify that time, I’d put it at 5 hours or less.

Secondly, I simply cannot inadvertently break the code. The test suite finds such breakage within seconds! And this makes me fearless. When you are fearless, you can go a lot faster.

Thirdly, My tests are little examples of how to work the system. Whenever I forget how some part of the system works, I read the tests. They quickly get me back up to speed.

Fourthly, I’m not fighting a continuous barrage of bugs from the field. Even though I have thousands of users, my bug list is tiny. The time I spend in support is less than an hour a week, and usually that’s just pointing people at the right spot in the user guide.

So to counter Kent Beck’s quote above: “When your code works you can go a lot faster.”

Summary

I’m quite sure this blog will not quell the controversy. I expect that those folks who consistently berate TDD will continue to do so. But perhaps those who have honest doubts will find this blog useful, or even convincing.

"TDD Triage" by christian louboutin

Sun, 30 Oct 2011 08:00:08 -0500

Good artical,I learn something!

"TDD Triage" by xsw123

Sun, 30 Oct 2011 04:05:56 -0500

??? ????1856??????????? ????????1835??????????? 1924??” ??? ????”??????????????????????????? ??????????? ??? ? ( Burberry) ??? ??????1856????????? ??? ???????????? ??? ??????????????????? ???????????? ? ??????????? ??? ???.
?? ?? ??????????????? ?? ?????????? ?? ?1968??????? ?? ???????????? ????????? ?? ???????? ?? ??????? ?? ??????? ?? ???????? ?????? ?????5 ?????????TOMS ??????????? ????????????????????????? ????????????Supra ????????? ?????????????? ??????

"TDD Triage" by xsw123

Sun, 30 Oct 2011 04:03:55 -0500

"TDD Triage" by xsw123

Sun, 30 Oct 2011 03:57:22 -0500

"TDD Triage" by xsw123

Sun, 30 Oct 2011 03:53:47 -0500

"TDD Triage" by Catherine

Mon, 17 Oct 2011 05:19:01 -0500

Oh my there are a lot of comments on this page! I think you should consider getting some sort of anti-spam solution or at least clean up a bit.. Maybe you could turn on comment moderation, though I guess that would be a ton of work so might not be viable.

"TDD Triage" by Tommy

Thu, 13 Oct 2011 05:17:26 -0500

Wow doesn’t anyone read the entire post before they post comments anymore? Some of the comments on this page are just really weird..

"TDD Triage" by Christian

Mon, 10 Oct 2011 23:21:53 -0500

as asd9+f8sa798+8s8s8sss

"TDD Triage" by moncler

Mon, 10 Oct 2011 23:03:53 -0500

asdf+098+9 fhf44ffff

"TDD Triage" by Louboutins

Mon, 10 Oct 2011 23:00:01 -0500

asd asd+f6s86s6ss

"TDD Triage" by louis vuitton handbags womens on sale

Fri, 16 Sep 2011 00:40:55 -0500

Those are amazing. Wonderful collection. This is real design. Love it man. Thank you so much for shearing.

"TDD Triage" by bagsupplyer

Sun, 04 Sep 2011 02:43:04 -0500

Good Luck!It is nice of you to post it. Discount fashion women Supra Lowcut shoes from China for wholesale free shipping,more order,more discount

"TDD Triage" by Ipaymu

Sun, 21 Aug 2011 08:54:44 -0500

This is one of the most incredible blogs Ive examine inside a extremely prolonged time. The level of details in right here is stunning, like you practically wrote the book around the topic. Your website is wonderful for any person who would like to fully grasp this topic a lot more. Wonderful things; please preserve it up!

"TDD Triage" by city tour abu dhabi

Wed, 17 Aug 2011 14:09:31 -0500

This is excellent post. I am very enjoyed for this blog,You truly did a good job.

"TDD Triage" by traumdeutung

Fri, 12 Aug 2011 04:37:35 -0500

Thanks for letting me discuss here.Really exciting and informative blog.Learn and enjoyed the staying very much.

"TDD Triage" by Bowtrol

Mon, 08 Aug 2011 17:14:00 -0500

hmm ,i’m not sure if this is what i’m looking for but anyway this is interresting and could be useful some day,thanks for taking time to write such cool stuff

"TDD Triage" by austin bail bonds

Tue, 12 Jul 2011 11:37:15 -0500

I am very enjoyed for this blog. Its an informative topic. It help me very much to solve some problems. Its opportunity are so fantastic and working style so speedy. I think it may be help all of you. Thanks a lot for enjoying this beauty blog with me. I am appreciating it very much! Looking forward to another great blog. Good luck to the author! all the best!

"TDD Triage" by new orleans evlt

Sat, 02 Jul 2011 15:00:31 -0500

It is nice to find a site about my interest. My first visit to your site is been a big help. Thank you for the efforts you been putting on making your site such an interesting and informative place to browse through. I’ll be visiting your site again to gather some more valuable information. You truly did a good job.

"TDD Triage" by complete websites for sale

Wed, 29 Jun 2011 07:16:08 -0500

This is excellent post. Its having good description regarding this topic.It is informative and helpful.I have known many information from this. Thanks for shearing.

complete websites for sale

"TDD Triage" by r4 ds

Wed, 15 Jun 2011 01:17:39 -0500

Nintendo DS & Lite consoles are using next generation flash card called as cheap r4 ds in the market. R4 DS, R4DS, The cheap r4 ds is the most famous nds card in the world today. R4, R4i-SDHC, Users should be tension free as cheap r4 ds is giving complete solution without any help of additional component in the market. r4i, buy r4, ds r4, Acekard 2i, Consumers should be aware with the features of cheap r4 ds now. The users of cheap r4 ds can avail best performances in the market. R4 card, r4i gold, Various activities like watching movies, playing MP3’s and storing hundreds of homebrew applications are handled by cheap r4 ds in the market. Under Creative Commons License: Attribution No Derivatives R4 nintendo, R4i, R4 Card, The cheap r4 ds is well known product of Nintendo DS flash card. Acekard 2i, Acekard2i, Dsi R4, The cheap r4 ds plays major role in the small and powerful nds. Even the cheap r4 ds carries the same apperance as the original nds cart in the market. R4 Dsi, R4 SDHC, Now most of the productions of cheap Nintendo R4 are done by branded companies in the world ???? .

"TDD Triage" by phoenix internet marketing

Sun, 12 Jun 2011 00:19:07 -0500

Great Article, I really enjoyed reading it.

"TDD Triage" by 123

Sat, 11 Jun 2011 02:56:56 -0500

5788

"TDD Triage" by osi layers explained

Wed, 08 Jun 2011 23:01:51 -0500

Great, I get improved with this.

"TDD Triage" by san dieago lawyer

Wed, 08 Jun 2011 10:02:22 -0500

Thanks for letting me discuss here.Really exciting and informative blog.Learn and enjoyed the staying very much.

"TDD Triage" by Jake

Tue, 07 Jun 2011 07:08:59 -0500

This post is great about TDD a replacement for architecture.That is helpful for anyone who is interested about this.So i would like to see more details on this topic