Hacker News new | ask | show | jobs
by jander 3958 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.
1 comments
anthonybsd 3958 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 3958 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 3958 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 3958 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