> it (TDD) makes you feel like a good programmer even if none of it necessarily contributes to the results your team is supposed to achieve.
It also, in my experience, often makes refactoring difficult because the implementation is set in stone, not the behaviour. I know the TDDers say this is because the tests are bad but, like agile, very few people seem to be able to "do it right".
> All of the really hard problems are not solved by TDD.
I've never seen TDD iterate towards good architecture. It optimizes for testable logic.
> A coding agent permits one to feel as if they have the raw productive power a great programmer can tap into. [...] Those cathedrals are not the great works they appear to be. The construction is shoddy and the architecture nonsensical
In other words, AI allows junior/mediocre devs to _feel_ experienced and produce naive implementations much faster, burying the experienced devs in the drudgery of code reviews and defect triage.
I swear almost every critique of test driven development boils down to "I wrote a bad test".
Yet TDD has no opinion on how you design your tests. There are people who say "you must do DI if you do TDD" or "TDD must be done with unit tests" and they are wrong but that is a separate conversation.
The author seems to disagree arguing that TDD is "pressuring" him to write tests in a certain way. Bull. He made a choice.
Invariably the shitty test which you write before because you overdid low level unit testing or DI is going to be just as shitty written after the code. Maybe a hint that PEBKAC?
>It’s an intoxicating way to work, especially for someone who struggles with software engineering. It makes you feel like a good programmer
I think somebody needs to get allll the way over themselves.
In my experience, the level of test coverage has little to no correlation to the quality and readability of the codebase.
These are subjective, of course, but some of the easiest codebases to understand had low test coverage, and some of the most complex codebases had high test coverage. The opposite has also been true.
If you're a startup and religiously using TDD from the very beginning without focusing on your core product and have little to no revenue coming in, you are wasting your time.
Once you have the revenue / funding and the paying customers then having TDD with thousands of tests makes a lot more sense.
I'm very hesitant to use an agent to completely generate lots tests unless you clearly know what to test for. Otherwise I write them myself.
> using TDD [...] without focusing on your core product
This. Even in large enterprises, I've seen projects prioritize code metrics over product metrics. A beautiful codebase that nobody uses is completely wasted effort.
A few quotes that resonated with me:
> it (TDD) makes you feel like a good programmer even if none of it necessarily contributes to the results your team is supposed to achieve.
It also, in my experience, often makes refactoring difficult because the implementation is set in stone, not the behaviour. I know the TDDers say this is because the tests are bad but, like agile, very few people seem to be able to "do it right".
> All of the really hard problems are not solved by TDD.
I've never seen TDD iterate towards good architecture. It optimizes for testable logic.
> A coding agent permits one to feel as if they have the raw productive power a great programmer can tap into. [...] Those cathedrals are not the great works they appear to be. The construction is shoddy and the architecture nonsensical
In other words, AI allows junior/mediocre devs to _feel_ experienced and produce naive implementations much faster, burying the experienced devs in the drudgery of code reviews and defect triage.
I swear almost every critique of test driven development boils down to "I wrote a bad test".
Yet TDD has no opinion on how you design your tests. There are people who say "you must do DI if you do TDD" or "TDD must be done with unit tests" and they are wrong but that is a separate conversation.
The author seems to disagree arguing that TDD is "pressuring" him to write tests in a certain way. Bull. He made a choice.
Invariably the shitty test which you write before because you overdid low level unit testing or DI is going to be just as shitty written after the code. Maybe a hint that PEBKAC?
>It’s an intoxicating way to work, especially for someone who struggles with software engineering. It makes you feel like a good programmer
I think somebody needs to get allll the way over themselves.
In my experience, the level of test coverage has little to no correlation to the quality and readability of the codebase.
These are subjective, of course, but some of the easiest codebases to understand had low test coverage, and some of the most complex codebases had high test coverage. The opposite has also been true.
For clarity, PEBKAC is "problem exists between keyboard and chair"
If you're a startup and religiously using TDD from the very beginning without focusing on your core product and have little to no revenue coming in, you are wasting your time.
Once you have the revenue / funding and the paying customers then having TDD with thousands of tests makes a lot more sense.
I'm very hesitant to use an agent to completely generate lots tests unless you clearly know what to test for. Otherwise I write them myself.
> using TDD [...] without focusing on your core product
This. Even in large enterprises, I've seen projects prioritize code metrics over product metrics. A beautiful codebase that nobody uses is completely wasted effort.