> challenge any claim that using something like TDD necessarily implies that your code will evolve a robust, modular design. Obviously there is not "necessity"

> challenge any claim that using something like TDD necessarily implies that your code will evolve a robust, modular design. Obviously there is not "necessity" here. You can indeed add more coupling with wrong tests. But this is a side effect of some excessive cargo cult about TDD and you should not throw the tool away because some overuse it. The claim that writing tests helps you define and describe you'r code interface still hold, and strongly. I usually code in Python and run pylint on my prose. When it tells me I shouldn't call a private method or attribute from outside, it is for me a warning sign: - I may not be testing the proper behavior. - If I feel I need to test it inside, this code nugget has too much responsibilities. - It may be the case that this private thing is really public (I am a private-by-default coder), but this is rare. When you don't have the time to refactor it properly, I admit that in some cases there are only bad choices: writing a long unatomic scenario testing, testing atomically inners, or not testing anything at all. The later is the easy path for short-sighted development, but adding some testing, even subpar, is much better, because at least it shows Someone Once New How To Roughly Run this part of the code base.