Hacker News new | ask | show | jobs
by HeyLaughingBoy 3956 days ago
No TDD != lack of unit testing.

I am a big believer in unit tests, but don't like TDD much. I think it fosters the belief that you can test quality into a product. Testing should be a verification that the rest of your process has resulted in a high quality product. It shouldn't be the means of getting quality into the product.
3 comments
crdoconnor 3956 days ago
TDD isn't about fostering the belief that you can test quality into a product. It's just a way of focusing your mind and ensuring your code gets run as early and often as possible so bugs are caught earlier.

FWIW, most people shouldn't be unit testing at all. They should be writing high level automated integration tests.

link
jander 3956 days ago
Hmm sorry, I've never heard of TDD guaranteeing quality of a product. It _might_ mean you've delivered what's been asked of you (along with acceptance testing) but quality? Far from it. And if you're unit testing _after_ the fact, then you're just asking for trouble.
link
anthonybsd 3956 days ago
I'm in the same boat. TDD might be suited for some narrow cases of development workflows. However, it doesn't do too well for others, and completely poorly for a vast category of things. Overall, if your Sprint defines good unit test coverage as criterion for "Dev Complete" it's more than sufficient.
link
crdoconnor 3956 days ago
>I'm in the same boat. TDD might be suited for some narrow cases of development workflows. However, it doesn't do too well for others, and completely poorly for a vast category of things.

I find where it works poorly it tends to just mean you have poor testing tools at your disposal.

Plus, people have a tendency to test things at far too low a level.

link
jander 3956 days ago
> Plus, people have a tendency to test things at far too low a level.

That's usually what drives people away from TDD. A very good approach for this is described at this article by Dave Hunt: https://medium.com/@davidihunt/tdd-and-complexity-1bbd5ca51e...

link
crdoconnor 3956 days ago
He's on sort of the right track but I don't believe this is true at all:

"Some have seen this solution to the shallow test problem and suggested that the ideal scope for our tests to target is the user interface, and to execute all the code in each test including framework and external components like the UI and the database.

Unfortunately the RoI of system testing is too low to do much of this. They’re slow, they’re brittle, they require careful environment setup and teardown, and they’re much more difficult to write and maintain than unit tests."

Slow is okay. It's better to be realistic than fast. You can also throw computing power (which is cheap) at slow. You can't throw computing power at unrealistic.

Brittle means either you have bugs which your test helpfully uncovered for you (e.g. race conditions) or you wrote a buggy test.

"Moreover, testing through the UI for every scenario in your code is just unnecessary"

It's almost always better to loosely couple your tests. It makes it easier to refactor the code that they test.

link
rbanffy 3956 days ago
One nice advantage of TDD is that you don't risk building a hard to test product. Of course, you have to pay attention to what you are testing and make your test cases meaningful.
link
HeyLaughingBoy 3956 days ago
I agree completely with this.

One of the problems I've seen ith TDD is that the team decides on a metric of minimum code coverage of x%. Now, in order to achieve x, a large number of basically useless tests end up being written simply for the sake of getting the coverage number up regardless of how poorly thought out those tests are.

That's not an inherent fault of TDD, of course. My point is that the mindset that seems to follow it leads to dumb things like that happening.

link