Wiki Objections To Working Test First

Answers to KayPentecost's harmless and mild question on the XpMailingList, read into evidence at ObjectionsToWorkingTestFirst.

Legend: Pro TDD arguments, Con TestDrivenDevelopment arguments.

"Tests are usually very simple, very modular code with mostly linear structure and no tricky dependencies or obscure control logic."

"Tests test themselves at the same time as they test the code. Test failure maybe either code defect or test defect."

"Test code is not deployed to production env, therefore defects in test code have no direct impact on the quality of the production system"

"TDD is not a silver bullet. Cases where a wrong test passes a wrong code are not unheard of, but are not frequent enough to be a major negative factor. Cases where a test that discovers a defect is not written are a much bigger problem."

-- AlexeyVerkhovsky

Tests make you research things the newbie tutorials don't teach you how to do.

Tests are easy to write - very simple, very modular code. So use easy things to make the hard things - ProductionCode - easy to write.

--PhlIp

"In the time that I spend writing tests, I could do a SpikeSolution, and get started thinking about the problem right away, in a much more direct manner."

"I don't have the patience to ignore the fact that I already know how to implement most of the unit. TDD seems to prevent me from skipping steps."

-- KarlKnechtel

"If you were a team player, you wouldn't keep writing these tests that break on your colleague's workstations" so they never run them.

--PointyHairedBoss

Code written test-first is really hacky and poorly structured. (heard at a programming workshop)

Yeah, and code written without any tests is really easy to clean up and polish...

If you fundamentally don't know how to solve a problem, test-first will just lead you around in circles with feel-good green-lights about minor details, leading to an illusion of progress.

Some objectives I have run into. I don't necessarily agree with the objectives, but one needs to be prepared to answer them.

I can see the solution so clearly, I don't want to stop and write the test first [from personal experience].
I've never had to write tests before and I'm a pretty good programmer. Why should I start now?
Programmers can't test their own code. We need to have independent testers.
We have people paid to be testers. Testing is beneath me. Testing is for those who cannot program.
If other programmers would just learn to do it right the first time, we wouldn't need to waste time testing at all.

I find these objections seem to be more psychological than anything, which only makes them more difficult to address. -- WayneMack

I like Test First, but the problem I have with it is that I've seen a lot of sloppy tests written. I tend to view a test as a proof in the mathematical analysis sense. I like to test the first and last values in a potential range, as well as somewhere in the middle, but a lot of tests I see just toss random data in there that sometimes has to be massaged to work correctly (Per comments like "This doesn't seem to work if you use now as a time in the range, but if we make it 5 hours ago it seems to work OK."

I also see a lot of unfactored code (cut and paste...) fail in the same way repeatedly as we all know unfactored code does. This is not a failing of test first, but it is something that doesn't seem to be caught by it well. The test first documents I've read seem to discourage the kind of paranoid testing necessary to catch issues related to these problems.

I'm not objecting to test first. I'm objecting to treating test first as a silver bullet, much as I would object to treating XML, Java, Object Oriented Programming or XP as a silver bullet. None of these will allow you to hire trained monkeys over experienced software developers. --BruceIde

From the comments listed, it does not appear test first design was used. The comment "This doesn't seem to work if you use now ..." only makes sense if the test was written after the code. If the developer had written the test using "now" first, it would have to pass before he wrote code to make any other value pass. Also, how can one possibly cut and paste code that fails when doing test first design? One may choose to copy and paste some code in response to a failing test, but if the test continues to fail after the code is inserted, one still needs to make it work (in the current situation - there is no conclusion to be drawn about the code's operation in its original location, though I would be suspicious).

Test First Design is not a Silver Bullet. It will not magically enforce thoroughness of either coding or testing. Developer written tests, whether written first or after the code, do document the minimal level of thoroughness applied. The developer may have been more thorough than the test show, and we may hope so, but we will never know. What we do know, is that the code is sufficient to pass the existing tests, and we can always expand the tests to see what additional conditions the code may or may not handle. Teaching Test First Design, teaching Testing Theory - these are ways to take "trained monkeys" and turn them into "software developers." And face it, we all started out as trained monkeys. --WayneMack