>大时投资。对于简单的情况下，你失去了大约20％的实际实现，但对于复杂的情况下，你失去更多。>额外的复杂性。对于复杂情况，您的测试用例很难计算，我建议在这种情况下尝试使用自动引用代码，它将在调试版本/测试运行中并行运行，而不是对最简单的情况进行单元测试。>设计影响。有时，设计在开始时不清楚，并且随着你的进展而发展 – 这将迫使你重做你的测试，这将产生大的时间损失。我建议在这种情况下推迟单元测试，直到你对设计有一些把握。>连续调节。对于数据结构和黑盒算法，单元测试将是完美的，但是对于倾向于改变，调整或微调的算法，这可能导致大的时间投入，人们可能声称是不合理的。所以使用它，当你认为它实际上适合系统，不强迫设计适合TDD。@H_301_2@