Test Driven Design : Developer Day Scotland 2

TDD? I don’t have time

I’ve had one of my talks accepted for Developer Day Scotland: talking about Test Driven Design. I’ve got a basic idea for a talk, but in the spirit of Alt.Net and open source development, I thought I’d throw this important subject out to the crowd. I’ve got a few ideas for the talk that I’ll outline below, but I’m looking for ideas and stories from others to help illustrate this point. Lest you think this is the easy way out, remember that I’ll be editing, compiling and delivering the talk, and I’ll get all the hecklers and tricky questions.

In return, I will release the presentation under a creative commons licence so that anyone else can take it, adapt it, and use it to help sell the principles of TDD to their colleagues. I’ll also make sure all contributors are included in the acknowledgments, provided they give me their name. If you want to give feedback, comments below are preferred as they’re public, but you can also send them to me via twitter ( @craignicol ) or via my gmail address (which I won’t give here to avoid spam harvesting, but it’s the same username as my twitter account)

The basic structure of the talk will be a series of slides titled with a reason not to to TDD, followed by a few suggestions why that reason is a myth, or is not as big a problem as you might think. Based on last year’s DDDS, I expect most of the audience will have come across unit testing, but I might need to add that to the sales pitch. I’ll list below the basic ideas I’ve got so far. Any arguments, expansions, examples or other feedback gratefully received.

I don’t have time

  • Do you have time to debug a live system?
  • Do you spend time adding new features?
  • Do you have the right tools?

I don’t need to test

  • Are you a perfect programmer?
  • Are you working alone?
  • Will you ever maintain your code?

I need to know about IoC, mocking, etc

  • Not when you start
  • Don’t let the terms scare you, it’s the principles that are important
  • The principles are worth learning

I love TDD, but I can’t get my team to adopt it

  • Don’t keep it to yourself. Show it off.
  • If you’re the lead, make it happen. CI is your friend.

I don’t know what tools to use

I need 100% code coverage

  • Have you been talking to Joel?
  • You don’t need 100%, but until you try and reach it, you don’t know what you don’t need.
  • You have to decide which of this, and many other aspects you feel comfortable with, and which you don’t.

Quality doesn’t matter

  • It matters to the customers who have to wait longer for a working product
  • It matters to the developers who have to maintain your code and will leave or stop caring
  • It matters to the accounting department who lose money for either of the above

You can’t test a UI

  • Make sure your logic can be tested without a UI
  • Test the right thing on your UI
  • There are frameworks (NUnitForms, WatiN)
Blogged with the Flock Browser

9 thoughts on “Test Driven Design : Developer Day Scotland 2

  1. re: “I don’t have time”: Although it’s counter-intuitive, in the medium and long term TDD is *quicker* because a) it makes your code more maintainable b) it improves confidence allowing you to make more radical changes c) it’s more fun

    Also maybe have something on integration vs unit testing – a common beginner’s mistake I come across is trying to test far too much functionality in each test


  2. Looks good, except I think NUnitForms has been discontinued. Would it be worth including Selenium and maybe pushing ASP.NET Mvc as a counter argument to ASP.NET being hard to test, for those still unaware for Mvc?


  3. Mike:

    I have to say that’s the reason I picked that title, by choosing the counter-intuitive myth. I have noticed that support and new features work a lot smoother and faster once testing is a standard part of a program.

    I’ll think about the ‘Testing is too complex’ argument as a way into integration vs unit testing. That’s a good idea. Thanks.


    I have to admit that I’ve not got much experience of the UI testing side of things, due to the nature of the projects I’ve worked on, so I’m happy to defer to any one else’s experience on this.


  4. Have to admit I’ve never had much luck testing UIs. NUnitForms, WatiN, Watir, Selenium, NUnitASP, I’ve tried them all and each time it’s quickly become too little benefit for the cost.

    The solution is to use MVP\MVP everywhere you have a UI – using ASP.NET Mvc if you want, or it’s trivial to roll your own.


    1. Robert, I’ve heard that excuse a lot. It’s a good one to add. I’ll have to think about the XP idea that some propose that programmers shouldn’t write their own tests, which I think sends people down the wrong path. I think it’s worth making the distinction between development testing and acceptance testing (which includes system tests, user testing, quality audits and all the other stuff people should do to prepare a release)


  5. It doesn’t help that software quality standards typically include “unit tests” among the things they require. If you read these documents you can quickly see that they are not really talking about XUnit-style automated tests. I often make the point that the XUnit-style tests are really a tool to improve programmer productivity, rather than another layer of quality assurance.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.