我的意思是，有时架构师会寻求简化和提高可测试性，却以牺牲其他重要力量为代价。
例如，我正在审查一个非常复杂的应用程序，它是通过广泛使用过分偏爱测试的设计模式(例如: IoC，DI，AOP等
现在，通常我喜欢这些东西，但是系统应该更简单-尽管不仅是数据库上CRUD的简单Web前端，它仍然没有比这更复杂(即使考虑到一些内部工作流程，流程等) )。另一方面，仅审查代码就成为heinie的一大难题，它几乎不可读(即使它写得很好)，而对代码进行编码肯定是一件痛苦的事情。
实现的复杂性明显违反了KISS(原则，不是乐队)...并且“唯一”的好处是使用测试框架和模拟以及...提高了可测试性。
现在，在您让TDD迷们跳动之前，我并没有轻视可测试性的重要性，但是我在质疑考虑使用这种特定力量(相对于其他所有力量)的至高无上性。
还是我错过了什么？
我想补充一点-在我看来，所有关于“可测试性”的论述都专门针对单元测试，它与整个系统测试不同，并且当单个单元处于测试状态时可能会导致错过测试整合在一起。至少，这似乎是IoC/DI进行测试的重点...
另外，我要指出的是，该系统(以及我看过的其他系统)每个接口(interface)只有一个具体对象，并且IoC/DI仅用于(您猜对了)用测试模型代替具体对象以测试仅测试。
我觉得有必要从Wikipedia on IoC添加此报价:
是的，这恰好表达了我的感受:D
最佳答案
为了回答您的一般性问题，我会说“一切都应适度”。当然，强调可测试性是一件好事。但是，如果要以排除可读代码或逻辑API为代价的话，则不是这样。