Exactly one of the reasons I never went down with all the TDD dogma of only writing code to fix broken tests.

There is a reason conference talks are always about plain algorithms and data structures.

The biggest flaw I've seen with TDD is the fact that correctness does not compose upward. Every time two units come into contact, you've got an entirely new kind of unit. The tests from constituents do not cover emergent properties of the new things. You will repeat this same exercise the entire way up to the top, and the moment you come into contact with the customer (they want to change everything), the house of cards comes crumbling down and you have to start your agonizingly-slow process all over from the bottom again.

The only thing that the business seems to care about is top-down UI testing. This is also convenient because you can leave it until the very end after the customer has already seen several prototypes.

I do think TDD makes sense in isolated scopes (prove this specific custom parser works at the edges), but as the general policy for the entire product it's definitely not a viable practice. Much of the time if comes off as an ego trip to see just how cleverly we can mock something so that we can say we technically tested it.

	▲	MoreQARespect 32 minutes ago \| parent \| next [-]
		That is a flaw with unit tests written at far too low a level, not with TDD. You would have the same problem if you wrote tests like that after the code. TDD has no opinion about the level at which you wrote your test, it just assumes it's the correct one. This is the number one biggest misconception about TDD which I keep seeing repeated on hacker news. https://news.ycombinator.com/item?id=46810793 https://news.ycombinator.com/item?id=45113016
	▲	bluGill an hour ago \| parent \| prev \| next [-]
		I tell people you should be testing at the level where a change would be so hard you wouldn't do it anyway. Internal helper functions - they are tested only because the code that calls them passes. Interfaces that are used thousands of places - you better test them well because you wouldn't dare change that anyway: it would break too many others. Or to put it differently: a test is an assertion that no matter what, for all time this should never change again. Even if customer requirements change in the future they won't change in such a way as to break this test (this isn't always true, but you should believe it is true). A test is most valuable when it alerts you to a real problem when it fails. If the test fails but there isn't a real problem (either because customer requirements have changed, or it is flaky) it was needless cost to investigate it. If the test passes that gives some hope of correctness, but you can never be sure it is really correct vs a bug in the test (even if you use TDD and so the test failed when you wrote it that doesn't mean a refactoring since didn't make this an always pass test). Part of the problem is if I tell you to write sort() or your new toy language's list type you have an intuitive idea of what it should look like and probably will get them right the first time (other than bugs you want the tests so you catch). These should have tiny micro tests. These things also are really easy to use as examples of how to do TDD - which they are, but they are not representative: this type of code is generally in your standard library already and you are not writing it. Instead you are writing code that isn't well defined with lots of industry experience. It is not clear what the exact interface should be (or more likely it is clear customer requirements will change but you don't know how yet). You have no idea what the best implementation is. You don't know if this will be used in this one place, or if it will become a useful key part that many future projects depend on. You have to make guesses.
	▲	pjmlp 2 hours ago \| parent \| prev \| next [-]
		Exactly, the whole system thinking and large scale architecture also fails apart, when writing everything from little working tests.
	▲	valvar 42 minutes ago \| parent \| prev [-]
		TDD is perfect for bugs; codify a replication first, then fix it.

▲

e12e 27 minutes ago | parent | prev | next [-]

> TDD dogma of only writing code to fix broken tests.

Isn't red-green-refactor pretty ingrained in TDD?

Only write code to make a failing test pass; then refactor while making sure the tests still pass?

Then write a test that fails, repeat?

▲

zuzululu an hour ago | parent | prev [-]

yup and I find it weird that people still remain so defensive of the Church of TDD even against empirical studies that show its limited benefits

https://arxiv.org/abs/2602.07900

▲

wolvesechoes an hour ago | parent [-]

Many such churches.

Substitute static typing for TDD in your comment, and it will remain equally valid statement.

	▲	mcapodici 3 minutes ago \| parent [-]
		Static typing is very useful and time saving. I can rename something, knowing my IDE can propogate the change. I can call a function and know what it expects, not just "a thing, hope they added a comment so I know what type/shape wont blow it up!". Here I am talking about the basic static typing, and maybe some generics use occasionally, but obviously people also go overboard sometimes with type features and that hinders understanding for newcomers to the codebase.