前端之家收集整理的这篇文章主要介绍了
单元测试 – 管理单元测试的维护负担，
前端之家小编觉得挺不错的，现在分享给大家，也给大家做个参考。
编码测试 – 首先，我发现我的
代码或许有3/4是单元测试;如果我真的极端，并没有写一行
代码，除了修复一个失败的单元测试，这个比率会更高。维护所有这些单元测试
增加了大量的惯性来编码更改。早期，我吸了它，修复他们。一旦有压力，我最终得到一个broken_unit_tests目录，以重新“有时间”。感觉就像TDD在很短的时间内进行高覆盖，在设计有时间结束之前。
如何找到我的出路这个困境，并开始欢迎不断变化的要求，我应该？
保持程序员纪律的方面搁置…(这是一个个人的事情，如果你没有做任何伙伴建立或没有完成所有的测试签入)敏捷承担高纪律和勇气和
支持留在右路径在压力:)，
如果你发现单个更改失败多次测试，它的气味，你的测试的东西是错误的。脆弱测试是常见的，当你开始与TDD …如果你花更多的时间修复你的测试比修复你的代码…停止，呼吸和反映。修复疾病，而不是症状。如果你有一些代码片段，我们可以讨论。因为它站在我不认为我可以帮助你了很多…指南：测试应该失败，只有一个原因。相反，每个失败的测试应该指出缺陷的确切唯一位置。两个测试不应该失败，由于相同的更改。除非你正在进行架构级扫描更改，这应该是罕见的。
原文链接：https://www.f2er.com/javaschema/282397.html
