Objections To Working Test First

A savage deceased equine flagellation mosh instigated by the usual instigatrix on the XpMailingList...

Legend: Pro, Con.

Ward's Wiki can get its lashes in at WikiObjectionsToWorkingTestFirst.

I'm working on compiling a list of reasons that people use to object to TestDrivenDevelopment and/or TestFirst.

I'm also interested in any pro Test First arguments that people have used, successfully or not.

But Kay - isn't that a bias to assume none of the Con arguments could have been successful?? --PhlIp

A related blog post, titled "The Cost of NOT Doing TDD": http://christiansepulveda.com/blog/archives/000040.html

TDD is "red, green, refactor". If we're under pressure, the refactor bit won't happen, and we'll be left with hacked code.

It results in a design that better suits the problem.

--TimHaughton?

It would slow me down.

Everyone knows that testing can't prove that a program works.

I already know a good design for my program so I don't need TDD.

Some things are hard to test.

--RonJeffries

Writing tests is boring.

I don't know how to write tests.

It won't catch the tricky bugs anyway.

--Daniel_org

One I just was presented with yesterday was, "I never know how to start. What is the first test I should write?" Or another variation is, "I don't know what test to write until I write the code."

Some of my failed attempts to help the developers using the above objections are:

If you can write the code first, there must be a test you could have written first.
Always start with the *simplest* test first, just to get the rhythm started.

Like I said, these haven't worked for me, so my next one is:

Let's pair up and try it together.

--JeffreyBrekke?

"Writing tests is additional work; the client won't pay for it."

--EdmundSchweppe?

The client won't pay for bugs, so I test to get more payable code.

--Thomas Eyde

"I already test my code by running it!"

"Test-driven development unnecessarily creates abstract overhead creating interfaces with only one real implementer."

"Test-driven development creates a maintenance nightmare, now I have to maintain twice the code!"

"Test-driven development's stressing of many small methods, classes and abstraction produces slow, highly inefficient code."

--ChrisWilliams?

If the client isn't willing to pay for automated tests, why would they agree to pay for manual tests? Perhaps they don't want to pay for any tests at all.

Writing tests is "additional work"? Additional to what? Manual testing? We're suggesting that you _replace_ manual testing with automated testing. So the time lost to automated testing is recovered by not doing manual testing.

You have to do testing; therefore you may as well automate the tests, so that you can run them again and again at marginal cost.

When you have some practice with automating tests, it doesn't take any longer to write and run an automated test than it does to devise and perform the same test manually. Advantages:

If it does take longer, the additional cost is incurred only once. Each time you re-run the automated test it costs nothing, while re-running manual tests is just as expensive each time as the first time.
Automated tests can be combined with code-coverage tools to ensure that you have explored the boundary cases. You _can_ explore boundary cases with manual testing; it just takes longer.

--AlistairBayley

"I forgot."

The following arguments assume the developer is willing to write tests, but is resisting test-first techniques...

It's more difficult to write tests for code after it's developed. One of the side effects of test first is that the code has to be testable as it's being written (by definition).

With test first / TDD you only write the code you need which is often less the the code you think you'll need. It keeps you focused on the simplest solution because the effort required to implement a complicated solution that's not really needed will be opposed by the the required effort by relativey complicated testing.

It encourages you to think relatively deeply about the software requirements before you start coding. This often results in less development backtracking and more development productivity.

You are almost guaranteed to have great code testing coverage.

--SteveBate?

"It takes twice as long."

"I can write my tests after writing the code."

"I don't need to test everything, just the difficult things."

"It's too hard to test the difficult things."

"It's not a substitute for proper up-front design."

"TDD promotes overconfidence in your code."

"Maintaining the tests takes longer than maintaining the code."

"The tests don't prove anything and are worthless." (this in a system where almost every test was a bad method-sequencing-based mock test.)

"Making a small change breaks lots of tests and takes a long time to fix." (from the same system)

"I'm a programmer, not a tester."

"My code doesn't need tests." (gotta like this one)

Pro: You vill enjoy it! Or else!

Almost no one has done TDD honestly and properly for more than a few weeks and come back saying it's a waste of time. Most of the time, you can see the lightbulb over their head and the glee in what TDD does for them. A story helps here; mine involves seeing this in JerryJackson, veteran coder and one of the first Java authors. It's fun, it's cool, it's a floor wax and dessert topping!

Pro: Tests are specs/documentation.

You can't write code without first specifying its detailed design. TDD is our way of making that a natural part of building the code. If you don't want to write tests, then you can choose to spend your time writing these nice thick documents with lots of pretty pictures, which you'll have to keep up to date constantly.

--JeffLangr

> "Writing tests is additional work; the client won't pay for it."

On a similar note (and similar to the "it will slow me down" objection), "If I tell my supervisor in a status report that I have a test written but not the code yet, he'll think I'm wasting time/productivity" or "he'll think I'm crazy (and unproductive) trying to write test for code that doesn't exist yet"

In terms of arguments for ... one that I've seen help with folks that have an attachment to waterfall or "V" lifecycle model is ...

"Think of the test as an extremely rigorous formal requirement/spec for the code you are about to write - one that is far more precise than english prose."

"Think of the test as the "V" model in its ideal form of getting requirements writers and testers together at the beginning. You're going it one better by making the requirement and the test be the same thing"

--EdmundSchweppe?

Just to expand on this a bit: there's no reason why you should have an incomplete unit test at status report time. As far as the acceptance test, you can always say that you're nailing down the test plan so you can be sure you meet it.

--JohnRoth

Objection: "We already have a large amount of legacy code in place, and writing new code would require way too much bootstrapping code just to get to the point of writing a test".

"We don't have the time"

"Try a mock object framework"

"Start with simpler code without any dependencies to get your feet wet"

"Future code you write in a TDD fashion will naturally lead to code that is more loosely coupled and easier to test"

"Try it, you'll never go back once you do -- at least that's my experience"

"I'm still amazed at the stupid typos I end up catching even in the simplest code -- stuff that would have had me pulling my hair out with a debugger, but that I now catch immediately without a second thought"

--PatrickOshaughnessey?

> "It's a total waste of time to test simple methods -- like getters > and setters"

I actually agree with this one. You shouldn't be testing getters & setters. BUT you shouldn't write them unless they are needed to get a test to pass.

--DaveAstels

"But, hey : the tests are also code ! Twice more code, twice more bugs. And who is going to test all those tests ?"

-- ChristopheThibaut

 > It would slow me down.

Some minor variations on that one:

"We need to schedule in a week for writing tests - maybe next month."

"Fred wrote some tests but they keep breaking so we don't run them anymore."

--TomCopeland

"It's hard to write tests." "It takes long time to write tests." "It is boring to write tests."

"The failure frequency will drop in the CSCI-test (acceptance test)" (And it did!)
"If a bug occurs it will be easier to pin down, and will take less time to fix."
"If a bug is fixed, we will know by regressiontests that no other error is introduced."
"The red-to-green-bar-syndrome gets everyone happier."

--/Mattias

We've already started the project and we didn't include TDD in our estimates.

Our application is mostly GUI and we can not do that test first.

It breaks my "flow".

I lose sight of the big picture when I spend my time writing so many small tests.

--pier@nbnet.nb.ca

TestFirstUserInterfaces ;-)

--PhlIp

That's not an optical illusion; it just looks like one.

--DaleEmery

See MoreObjectionsToWorkingTestFirst, WikiObjectionsToWorkingTestFirst