这是真的，有时我添加的东西，为了使它更容易测试API，但我几乎总是发现，我认为我只是为了可测性的事情，实际上是非常有用的监测目的。因此，例如，一个FooAllocator最终可能有一个可选的构造函数参数，它是一个监视接口(IMonitorFooAllocations)，这对于在测试期间进行模拟非常有用，使我能够看到内部，但是当你突然发现你必须在生产过程中向世界其他地方暴露一些分配指标。我现在倾向于考虑我可能想要添加的额外的位，以便在可选的生产监控的双重用途方面进行简单的测试。我通常写服务器代码，并能够暴露内部的东西作为perfmon计数器是非常有用的…

同样，你说的通常是组成一个API的对象可能会明确地采取一些其他对象，而不是伸出来，从一个已知的地方，但这是一件好事。相信我，一旦你习惯了处理显式的依赖，你不想回到不得不在类后挖掘，以了解如何和为什么你的Widget访问活动目录，当没有提示在API，他们会想做这样的事情。另外，通常情况下，你在设计和测试期间打破这些依赖关系，然后再把它们隐藏起来，因为你把所有的部分放在一起。你仍然’从上面参数化’，但更多的时候，不是一个API的对象模型可能意味着你从来没有真正看到作为API的用户’上面’。你最终有一个地方配置的API，它需要的东西，通常这看起来没有什么不同，如果你有大量的单身，全局和隐藏的依赖关系。

但请记住，TDD是一个工具，当它不适合不使用它。