Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

There's something I really don't understand about all this uproar. TDD is build test first, write software later.

So people against TDD aren't against test units. They are against testing FIRST, writing software LATER.

We all agree that testing is part of the solution, how and when are the subjects of discussion.



While this is true, DHH in his article largely dismissed not merely testing first, but unit tests altogether, explaining that he prefers to focused on system tests. This set the tone to many subsequent reactions.

But there's no reason to tie TDD and unit testing together. Many people who dislike TDD swear by unit tests and most of their testing code is unit tests. They merely prefer to think of TDD as a much too extreme form of unit testing that turns out to harm more than it helps.

From that point of view (which I share), DHH's rant is puzzling. It's like that meme with Michael Phelps' mom. He's against TDD! Yay! Down with unit-testing! Wait, what?

"Less emphasis on unit tests, because we're no longer doing test-first as a design practice, and more emphasis on, yes, slow, system tests." Huh? How does that follow? How about, let's not do test-first as a design practice, and _still_ retain emphasis on unit tests? Because they catch plenty of bugs, because they exercise more functionality than system tests will, because in dynamic languages they protect you from silly type errors, because they make refactoring merely unpleasant instead of a horror show...


This may be a confusion due to overloaded words. In rails you often write tests against a real instance of a database using fixtures to load data, and roll back the state after the test.

Many TDD type people will shout at you "those aren't unit tests, you must write an abstraction layer that allows you to separate your model from the database". DHH is conceding to their definition of the word. He's advocating tests of the units of logic in your model, but not isolating it from a database with an abstraction layer. Therefore, not unit tests.


I personally prefer to write software firsts and tests immediately afterwards. I really think the idea of constantly refactoring both tests and code until the end purpose is reached is somewhat silly.

I'll typically write something that does what I want it to do, and keep it small and testable. Afterwards, I write the tests, then I refactor the original code to make it cleaner being able to rely on the fact that the tests ensure the refactor did not break the original intent.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: