I was hoping for an article that would explain about trade offs and when (pure) unit tests aren’t worth it. Unfortunately it’s just another article that makes it harder to have serious discussions about when to use which kinds of tests, because they paint all reasons against certain kinds of tests with the same brush. E.g. writing true unit tests for a unit that is currently “too complex” is a waste of effort. That’s a perfectly valid ‘excuse’. You should be writing contract/collaboration/integration tests for it. Unit tests are useful for certain kinds of units. Not every unit, even in a well designed, well coded system, is such a unit. For every unit you should ask the question: should I unit test this one?
That’s not what I read into the article. I interpreted it as: some (many?) development teams recognise TDD as a useful tool to aid design and improve robustness, and then try to dogmatically shoehorn this tool into every context possible. This is an unreasonable position to maintain, and it’s usually futile trying to reason against people who are brainwashed into believing test coverage is a valuable end goal for a business, so this article provides some equally unreasonable and flippant ammunition to counter with.