[Driky]

I would laugh if it wasn't so crazy that someone that doesn't know how to do TDD was writing an article to say it sucks. EDIT: after reading the blog post a second time, I even think that the author doesn't know how to write more classical unit-test.

[meowface]

I completely agree with the author, and have seen more and more anti-TDD sentiment in recent years. Certainly nowhere near all, but some TDD adherents seem to have a bit of a cargo cult mentality regarding it.

At the end of the day, I think whatever you're personally most productive with is what you should use. If it's TDD, use it. If it isn't, don't. Kind of like the saying "the best diet is the one you stick to". Maybe you could be more productive switching to it, or away from it, so it's worth evaluating alternatives carefully, but in general I think whatever works for you is fine to use.

[gmiller123456]

What is it the author said that makes you think he didn't know how to do TDD? Or write unit tests?

[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?

[DerpyBaby123]

>Read any advocacy of TDD and it will always boil down to an argument for testing itself, which nobody argues against. It never makes a case for writing tests before implementation.

It seems the author hasn't read many cases about TDD, which could be evidence they haven't learned much about it.

For example, from Martin Fowler[1]: "The second benefit is that thinking about the test first forces you to think about the interface to the code first. This focus on interface and how you use a class helps you separate interface from implementation."

[1]https://www.martinfowler.com/bliki/TestDrivenDevelopment.htm...

[sorokod]

Nobody argues against writing interfaces...

[Driky]

from what author is writing, he present his understanding of TDD as being "writing ALL the test before the implementation." And that would indeed be crazy. But TDD is not that. And again the author doesn't want to write unit test at the end of his project because he would have to "split the project into unit". Should your code be written using good practices you will be able to test it without having to split anything. Not being able to unit-test your code is a proof of bad design.