不可测试的代码真的让我烦恼。 以下事项使oo-code不可测试：
是否有更多警示标志？
答案 0 :(得分：12)
这些都不会使代码无法测试。它们可能会使查找边缘案例错误变得更加困难，但是，如果您已经完全指定了测试的成功标准（以及测试驱动的开发使这一点变得容易），那么您所要做的就是通过标准。
TDD可以应用于特定零件的行为以及整个项目，因此您可以轻松地测试非常小的组件。但是，它的意思是测试结果，不获得这些结果的方法。
如果测试通过，您已满足要求。如果存在错误，则这是测试的问题，而不是正在测试的代码（在这种情况下，应该修改测试以捕获先前无法预料的问题）。
你不应该关心（在功能交付方面）你的一个构造函数中是否有while语句。你应该问问自己有哪些业务要求？我强烈怀疑您的客户会提供一系列要求，包括“继承限于4级”。他们可能会将“无错误”列为要求，但您必须在那个问题上进行协商： - ）。
答案 1 :(得分：11)
请参阅MiškoHevery的以下博文：How to Write 3v1L, Untestable Code。
答案 2 :(得分：6)
硬编码依赖项。
答案 3 :(得分：4)
答案 4 :(得分：1)
在GUI类中完成的工作与表示无关。 GUI应该与底层模型完全分离。
答案 5 :(得分：1)
代码是不可测试的，只要您无法修改它。如果你有可能重构项目，没有代码是不可测试的。通常，只需要非常小的修改就可以使测试更容易。而且它们可以被证明是合理的，因为它们可以提高代码的质量。
即使在您描述的情况下，代码也不一定是不可测试的。这个测试更加困难。例如，如果您可以隔离数据库访问并在单元测试期间避免使用它们，则更容易测试代码。但如果必须，您可以建立一个专门用于运行测试的数据库。
答案 6 :(得分：1)
我会说这些事情都不会使代码无法测试。它们确实使单元测试变得困难，因为每个都会增加实现中的耦合。
使单元测试困难的其他烦恼：
一般而言，您可能会听到有关创建更好代码的任何建议，这也是建议更容易使用单元测试代码。
答案 7 :(得分：1)
数据库！特别是有触发器的那些！
我知道你可以模拟数据库，但我总是发现我的代码中的大多数错误（主要是CRUD应用程序）都是数据/映射问题，如果你模拟数据库，你就找不到那种错误。
答案 8 :(得分：1)
Writing Testable Code上的MiškoHevery指南详细说明了使代码难以测试的缺陷。他的名单与你的名单有些重叠，但却有着令人难以置信的细节。
答案 9 :(得分：0)
没有分层，耦合过多...即已经编写了Y类来了解X，但它不应该，X是可重用的。可测试性和可重用性之间存在密切关系。