I'm throwing my hands in the air in despair.  I've drunk the Kool-Aid, bought the hype and taken to my code with a big test driven club.  I'm not supposed to feel this frustrated am I?  Despite my best attempts to chain it up in the basement of my subconscious mind there's a little voice in my head calling out to me...  You're wasting your time...

I'm Talking About You Internet

Before I go an offend a whole spectrum of TDD believers I want to narrow down my focus a bit and concentrate on offending just a specific group of them.  The problem I'm having is my productivity when working on front end web pages has gone down by an order of magnitude.

I'm sold on the domain, the business logic, the services and the delicately encapsulated, exquisitely patterned classes separated with the utmost of concerns.  I don't mind spending time here and I'm seeing returns so I'm happy.

When it comes to the web I'm used to working fast and light and moving on quickly.  The tools support this well or maybe it's that they don't support anything else well.  The problem is that now I'm trying to smother my code in an air tight blanket of tests my fast and light web interfaces are gasping for air and fast falling behind.  The real WTF here is that despite the totalitarian rule of test coverage a lot of bugs are still slipping through.

Use A Bigger Hammer

The big problem is that despite using MVP to TDD my ASP my HTML is still AFK with my CSS and AFAIK it's got a freaking great BUG in it.  What?  I mean the tests don't cover my views and this is a big thing in a world where where anything but Web 2.0 is sin and AJAX roams around freely with little regard for the desperate cries of the programmers trying to tame it.

So tests aren't working out, what should I do about it?  How about some more tests?  Enter, the Watin!

Now don't get me wrong because I think Watin and the like are great tools but my poor code has a hard enough time cowering under the shadow of the mighty xUnit empire without being taken by a surprise attack from behind.  Watin is great for general functional tests but it's not the right tool for achieving code coverage and it keeps trying to bully my refactoring into giving up it's lunch money.

Time To Sober Up

As this all spirals out of control the voice in my head only grows louder but now it's screaming out to me...

Why?  Why?!  Wwwwwwhhhhhhhhyyyhhyyyyyyyyyyyyy...

Huh.  Why?  Well because you told me to.  Yes you.  Then who?  Well someone did.  Testing is good so more testing must be better right?  Because it adds value...

Aha!  Value.  So if I'm testing because it adds value then it would make sense to stop when it stops adding value wouldn't it?  If I'm so far over the edge that I feel like I'm taking value away then it's time for an intervention.  I like to know what I'm measuring so here's a quick list of the places TDD adds value for me:

• It helps me write code with less bugs.
• It proves that the code I have tested works as I expect it to.
• It enables me to refactor more effectively when changes are needed.
• It helps me design better interfaces for users of my code.
• It makes the world a better place (?!).

So when don't these things apply?

Where Did My Value Go?

More and more of what I do with ASP.Net is getting wrapped up in whiz bang designers with draggy droppy widgety things that try to make the endless configuration files we've introduced more palatable.  The nerd in me doesn't want this to happen because he loves code and I'm inclined to support him because it's pretty hard to wrap a meaningful test around a configuration file.

Lately I'm trying my best to be cool and hang out with the Web 2.0 crowd.  That means the combined total of the HTML, CSS, JavaScript, AJAX and configuration files for any particular page add up to a lot more potential mistakes than there ever could be in the short code behind I need to support them.  I can test aspects of JavaScript with something like QUnit and do my best to cover the functional aspects with Watin but there is barely even a glimmer of hope for the CSS and visual aspects of the site.

If TDD doubles the value of my work but means it takes me twice as long to do it have I actually gained anything?  When it comes to the code heavy business domain layers of my applications I'm quite confident saying I'm getting more than double the value.   In the UI I'm covering less than half of the meaningful decisions that go into any particular web page so its much harder to justify.

A Hard And Fast Rule For Sometimes

Every time I say it depends a thousand clients cry out in pain so block your ears, here it comes again.  There are many different flavours of web and it's all about the right tool for the right job.  Since my brain isn't likely to last long if I go through this little episode of insanity on every project here's my definitive guide to what you might maybe possibly should do.

Your web projects will benefit from TDD when:

• Your project is big.
• Interesting things happen in the code behind for your pages.
• You will have to support, maintain or extend the project in future.
• You are really building an application that just happens to be exposed via the web.
• Bugs are a big deal and your client is prepared to pay to prevent them.
• Your team knows how to do it and you already have the processes in place.
• You unit testing is combined with acceptance testing to make sure you build the right thing.

It will cost you more pain than it's worth when:

• Your project is small.
• The pages in the site present content and don't have any interesting functionality.
• Introducing MVC or MVP patterns causes more complexity and introduces more potential bugs than it saves.
• You're going to deploy the code and forget about it.
• You are building visual marketing driven sites.
• Bugs are not the end of the world and the client is prepared to deal with them as they come.
• You have other quality control processes that are working effectively.

Since those sets of conditions exclude a few pretty common scenarios here's a couple where you've got bigger issues than whether or not to TDD:

• You don't know what your project is.
• Your client doesn't believe in bugs.
• You don't have any quality control processes at all.

A Peace Offering

So I'm still allowed to hang out with all the cool agile kids I should clarify what I didn't mean in the post title.  I'm trying to say that for me test driven development isn't a linear trade off against productivity.  It's more like some bizarre polynomial function they tried to get you to derive in that algebra paper you failed at university.  Used in the right places it's a tool that can add a tremendous amount of value to the work you do but that value quickly degrades in certain scenarios so put some of that gray matter to use and figure out what it means for you.

Certainly some of my frustration deserves to be directed at current tool sets because they aren't designed for the kind of workflow I'm trying to achieve.  One thing I'll be looking at in future is the tools and the way in which I'm applying them.  My hope is that I can shift the balance to a point where TDD offers me a lot more values in the untamed wilderness of my UI.

Labels: ASP.Net, Style, TDD

Bookmark this on Delicious