TDD has costs. It's expensive and only works on certain types of systems. It also makes exploration of the problem domain extremely costly and makes refactoring a nightmare. I dislike TDD full stop but there are some domains where it's unambiguously a bad idea.
It implies:
- Behaviour can and should be compartmentalised
- Certain types of efficiency are ignorable
- Data structures are better off being relatively simple
- Behaviour is able to be understood before the system emerges
- The system doesn't fundamentally need a lot of mutable state
- Dispersing functionality across small, atomic functions (that obscure sequential flow and state mutation) is good for the code
- It is easy to extract the functionality of this system into pure functions
- A high-level veiw of the system is unnecessary (!)
- In this system, most bugs will come from small units, not interactions between units
- Behaviour of units is likely to be relatively unchanging
- Refactoring primarily happens between interfaces, not to them
- Test rigging is cheap and easy at every level of abstraction, or at least that it's better to contort your system into a structure where that's true
The only thing that somewhat makes sense is that during exploration TDD may not always be the most practical. It immediately starts to be extremely practical once the exploratory phase is over.
I kind of feel you live in some kind of alternate universe. None of these sound true to me, at all. The most important misunderstanding that seems to be going on here is the assumption that in TDD it is a given that one is testing single classes and/or methods. This is not the case. In fact, in most cases it is much more beneficial to test a set of classes/methods at the same time in a way that is representative of something that the customer values.
Honestly, I have seen TDD work so well in so many different circumstances that I have started to consider people who do not do not write test for most possible scenarios as being on the not-so-very professional side of things.
It implies:
- Behaviour can and should be compartmentalised
- Certain types of efficiency are ignorable
- Data structures are better off being relatively simple
- Behaviour is able to be understood before the system emerges
- The system doesn't fundamentally need a lot of mutable state
- Dispersing functionality across small, atomic functions (that obscure sequential flow and state mutation) is good for the code
- It is easy to extract the functionality of this system into pure functions
- A high-level veiw of the system is unnecessary (!)
- In this system, most bugs will come from small units, not interactions between units
- Behaviour of units is likely to be relatively unchanging
- Refactoring primarily happens between interfaces, not to them
- Test rigging is cheap and easy at every level of abstraction, or at least that it's better to contort your system into a structure where that's true
None of these things are a given.