TDD is a waste of time

What is TDD?

TDD stands for Test-Driven Development.

In the olden days, we got some requirements from a customer or a systems analyst or a business analyst or our software development manager. The requirements were probably a 200 page Word document that someone who got paid three times what you earn spent several months writing. Most of it will be impenetrable crap that takes you just as long to parse.

You parsed the requirements.

You fired up your editor (probably a hugely bloated IDE).

You wrote code.

You compiled the code and ran it.

You tried it out. It broke.

You edited the code, compiled it and ran it.

You tried it out. It broke.

You repeated the above steps a few times till it’s right.

You got it approved and shipped it.

The client came back and pointed out a clause in the huge document that you missed.

Or an existing feature that no longer worked when it did on the previous version.

You fired up your editor.

And so on.

After a year of this you stare at the mass of tangled spaghetti code and think about changing jobs.

What are its benefits?

Test-Driven Development is the silver bullet.

Amazing code that’s clean and easily understood.

It meets the client’s requirements.

It is easily updated as future features become apparent.

You never have bugs.

You feel happier.

Your husband or wife loves you more and becomes more attractive.

The birds sing louder.

What are its drawbacks?

It’s bloody hard work.

It takes a lot longer to get to shippable code.

It takes a lot of discipline to write decent tests.

It can be a pain when things change and you have to go back and change not just your code, but also your tests.

You still have bugs.

And did I say it takes a lot longer to get to shippable code. And now your boss hates you for it.

What types of tests are there?

There are lots of different types of tests. The terminology for them is confused, especially in Rails. But practitioners of TDD argue about the exact terms and what they mean anyway.

There are functional tests, unit tests, integration tests, full-stack tests, feature tests, discovery tests, blood tests, kitchen sink tests, test tubes, testes.

Should I do it?

The short answer: yes.

The long answer: yes, but do it right.

How do I do it?

Well, that’s the question isn’t it?

Over the next few days, I’m going to explain how I write tests in my Rails applications. It involves what I call “full-stack tests” and “discovery tests” (thanks to Justin Searls for that term).

It also involves a particular architecture for your Rails applications, that’s somewhat different to your standard ones. Nothing too radical, and hopefully it should be clear why I do things the way I do.

Click here for next exciting installment in this series (or sign up below to get a weekly update).

Do you know what to do but not how it works?

Ever wanted to understand why Rails views work the way that they do? Why variables from your controllers are visible inside your views?

Sign up below to get a free 5 part email course on how Ruby on Rails view rendering works and gain a deep understanding of the Rails magic.

We will send you the course, plus the occasional update from this web-site. But no spam, we promise, and it's easy to unsubscribe