[crdoconnor]

>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.

[jander]

> 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...

[crdoconnor]

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.