Listen to this post
Project managers have to balance resources. Spending them on one thing means not spending them on another. So, when the team adopts TDD, it is understandable that attention is paid to the level of resource needed to sustain it over time.
It’s not uncommon for project managers to notice, as the project grows, that the creation of tests and their maintenance seems to be an increasingly large drain on resources. Team leads may note that the suite of tests is actually larger than the production code base, sometimes far, far larger.
When this happens, an examination of the test suite will very often reveal that many of the tests in it are not written to express the specification of desired behavior, but rather to guard against unwanted behavior (bugs). These “protective tests” do not express business value, they indicate a lack of encapsulation in the system. If there was more robust encapsulation, they would not be needed because more bugs would be prevented by the compiler or run-time engine.
This could mean the design is weak or that the technology being used lacks enough enforcement of encapsulation, but in any case, it is a diagnosis of a problem which should be addressed. If it is, the test suite will end up fundamentally smaller and cheaper to maintain.