I have been on and off the TDD bandwagon and now I understand why. In order to have an enjoyable TDD experience, your tests must 1) be easy to write, 2) easy to debug and 3) finish running in seconds. Easy to write: that's mostly a process of structuring your code to be testable, something that is - although not always easy - at least straightforward. Easy to debug: very much depends on the language and framework(s) you are using. But if your tests run long, you starting waiting around for the tests to finish, and before you know it you are checking twitter and listening to podcasts(from Giles Bowkett). Your productivity go way down, and you get miserable - that is, if you care about your productivity. The hardcore TDD guys are big into using mocks, and the reason they give is the running time of the tests. Because with mocks they don't have to actually run any significant portion of code - the code is very hollow - the tests can run really fast. But, although I like mocks, they don't work everywhere. One example is Selenium. You may say, Selenium is not for TDD! It's for functional testing. Yeah, but why not? Selenium is starting to work well for me. It runs your tests against real browsers, and it can run your tests across different browsers automatically. Since, we have a lot of javascript in our app, I don't think any test suite that doesn't actually test your js against the actual browser gives you any real assurance. The problem with selenium, of course, is that it runs slow. Thus, my challenge, shall be to make my selenium tests run fast enough that I'd no longer have to wait around for my tests to finish(probably under 10 seconds). The first strategy I am going to use is to reuse test fixtures across tests in a fine grain way, so we can save much of the time used for setUp/tearDown.