[AndroTux]

“Oh, I can see the test is failing. Let me fix this by adjusting the test to expect the currently returned value.”

This is unfortunately an actual quote I got from Claude Code after having it write a unit test for me.

It ended up mocking the entire method it was supposed to test, resulting in the unit test essentially only testing itself.

[cjbgkagh]

Sounds very human. I experienced some junior devs who grew up with TDD and would often just tweak their code to pass their tests without stopping to understand their code at a fundamental level - essentially development through trial and error. Since they were also the ones writing the tests the core assumptions went into both and because they did so without thinking they were more likely to have errors. The test being wrong was more than likely and in those cases it would make sense to fix the test output.

[pydry]

TDD only really works if the test in some sense mirrors the specification.

Sometimes people manage it in which case it resembles a mini superpower but mostly they do not.

If it mirrors the spec then few people would change it to be wrong to make the test work.

[cjbgkagh]

AFAIK TDD culturally occurred at the same time as the push for 100% test coverage. So we would end up with code bases that were 90% test code and 10% actual code, every individual method had many tests. This meant for every code change there was a 10x test change so test timelines dominated dev timelines, there was a push at the time to expand the test org to be 2x the size of the dev org. AFAIK at MS that was abandoned and the test org was folded into the dev org and now the devs are expected to write and maintain their own tests.

I have only seen TDD used poorly, as a crutch, an alternative to thinking deeply about the problem space. If it can be done well I have not personally seen it. Perhaps SQLite, but such projects are an oddity.

To me tests at the spec level are largely user acceptance tests which are indeed very useful.

[pydry]

The push wasn't to test every individual method but to test every individual code change. This confusion you had was shared by many others and caused havoc because if you unnecessarily couple every single interface in the code base to a test then every change breaks a test. This became worse for many people than not writing tests at all.

>I have only seen TDD used poorly, as a crutch, an alternative to thinking deeply about the problem space. If it can be done well I have not personally seen it. Perhaps SQLite, but such projects are an oddity.

Theyre not that odd. I've applied it to every type of code base I've come across.

>To me tests at the spec level are largely user acceptance tests which are indeed very useful.

Where I use TDD the tests are exactly like this - written at the highest level possible using a shared framework that integrates sophisticated fakes which carefully balance realism, speed and flakiness. They all follow roughly the same pattern across the code base and that pattern mirrors the spec scenarios.

Where I see TDD used by people who complain about it they usually think the idea is to write a test for a class because they're thinking about writing a class. It is generally taught badly.

[cjbgkagh]

It sounds like your definition of TDD is regression tests + user acceptance test and I've already agreed that those are good things, we seem to just disagree that is TDD is generally practiced in this manner - though you've only given me your personal anecdote. I made a generalization based on an observed pattern of behavior at a rather large scale, I will assume that you do TDD as is intended, but I already assumed individual counters to my generalization existed so your anecdote has changed nothing. The question remains, does the generalization hold for the general case. Like the USSR made a valiant effort to achieve true socialism Microsoft made a valiant effort to implement true TDD before giving up in 2014.

[pydry]

The definition is you write or amend a test before making the code change that makes it pass.

That's it. It says nothing about the type of test you write. Personally i do it with literally every type of test that i write - acceptance, integration, unit.

If you write a decent test, yes, TDD is always valuable. If you TDD with shitty tests, not so much, but that isnt really an issue with TDD.

[hinkley]

Because AI is learning from humans and half of coders suck.

[tempodox]

Now I understand how people who let LLMs write their code for them come to believe it boosts their productivity. /s