[ergothus]

> Note that (4) may happen dozens of times in the course of a large project, and that every single revisit of the TDD tests is 100% wasted time.

^ That is what makes me (Note: I'm not the one you asked the question of) suspicious of the author's understanding.

This is the scenario they were describing:

> 1. write the TDD tests

> 2. begin implementation

> 3. discover an unanticipated consideration

> 4. rewrite the tests

Since the tests themselves didn't reveal the unanticipated scenario, that means it was in using a dependency, not in the API/interface of their code. Fair enough. But the argument that the tests are wasted is effectively saying "making sure the API/interface I was going to use actually worked" was wasted time.

I'm a fan of TDD, but hardly a fanatic, and honestly I've had limited opportunities to practice it lately. I think one of the major benefits of TDD is not using it, but the behaviors it teaches you - confirming your interface, making each piece small and decoupled - the things that make something testable happen to also be best practices for coding. This author isn't focused on the areas that actually doing TDD becomes complex, this author is tearing down those best practices by calling it "100% wasted time"

That's a much harder sell, and I'm not being convinced by this article.

[gmiller123456]

>"making sure the API/interface I was going to use actually worked" was wasted time.

That's not how I interpret his statement at all. I think he's saying the specs changed, so writing the tests for the previous version of the specs was a waste of time.

[ergothus]

> I think he's saying the specs changed, so writing the tests for the previous version of the specs was a waste of time.

...and instead they'd prefer to write code that was a waste of time?

If the issue is that time is being wasted, the tests aren't the problem. What the tests do (define, confirm the interface, ensure modularity and decoupling) is part of writing good code, and saying "but if I skip that part it's faster" is an illusion because you're skipping ahead to lower quality results.

When I first did TDD, it took about 6 months before I was as productive as I was before. After that, though, I was roughly equal in productivity (or faster,) AND my code was better quality (this is anecdotal and hard to quantify, but my coworkers and following job-switch serve to confirm). When I deal with problems where TDD is bad (exploratory throwaway code, code highly coupled to an external data source that is complex to mock, and with browser rendering) I still follow the same ideas as TDD - often writing a test that can't run, but that defines the interface.

I don't recall the exact quote, but there's a saying something like "programmers code, great programmers think about code". Tests are thinking. If you're not using your tests to think, you are in fact wasting time.

The author is pointing to the fact that they're wasting time and blaming TDD - Consider what their code looks like if they find the test-writing to be so wasteful. I'd guess they're either a genius-level coder with fantastic instincts...or they write code that is hard to test in the first place because of poor practices. As I and most of us don't have perfect coding instincts, if the author does have such ability, their practices aren't useful to me. And if they instead write poor code, why am I taking this advice?