共计 1414 个字符，预计需要花费 4 分钟才能阅读完成。
优良的测试套件能够让人在更改代码时感到平安，从而使工作更为轻松；蹩脚的测试套件会让人痛苦不堪，且节约大量工夫。编写好的、可保护的单元测试存在着一些特定规定，可使单元测试品质更高、更具效率。
1、尽可能简短
因为咱们测试的是由单个代码单元交付的单个性能，所以测试应该相当短是有意义的。至于具体须要多短就取决于多种因素，但通常不会超过几行代码。
2、切忌自我反复
良好的编码实际利用于测试代码的形式与利用于生产代码的形式雷同。从实践经验上来说，单元测试中最容易违反的规定之一是“Dont Repeat Yourself”。有些人甚至宣称单元测试基本不应该共享任何代码。那是全然的废话。当然，咱们心愿尽可能放弃测试的可读性，然而复制粘贴不是解决方案。
3、抉择组合而非继承
一旦理解了后面的两点，你可能会想要为本人的测试创立一些蕴含罕用代码的基类。如果的确如此，请立马进行！这样的基类就像磁铁一样吸引着各种不相干的共享代码，并且增长十分迅速，直到接管你的我的项目、迭代、产品……为保障这些不被它逐渐侵蚀，务必应用组合形式！
4、使其速度更快
单元测试简直能够始终运行。出于这个起因，肯定要模仿内部依赖项和其余可能会减慢测试速度的货色，这通常是数据库、内部零碎或文件操作。同时，不要做得太过——齐全隔离被测单元也不是一个好的解决方案。
5、使其具备确定性
每当听到有人领有了 95% 的可用测试套件，并认为这曾经足够好到能够投入生产时，我总是啼笑皆非，因为单元测试应该必须保障 100% 可工作性。只有 100% 通过测试才意味着一切正常（对于单元，您还须要其余类型的测试）。如果你的单元测试看起来不牢靠，请确保找到根本原因并尽快修复它。
6、不要为测试标注“可疏忽”
在第四条和第五条的根底上，必须要提及的是给测试增加“可疏忽”正文，这并不是修复测试套件的办法，反而会使测试套件更加不牢靠，因为它并不能防止回归 Bug 之类的问题。
7、测试你的测试
这一条不是说为你的测试编写测试，而是指进行如渐变测试、测试驱动开发或频繁地在代码库中“随机更改货色”这样的实际，以查看是否有测试失败。还能够常常做一些脑力练习，试图找出本人的测试中无奈发现的对代码的潜在更改。
8、正当命名测试
只管我不置信每个我的项目都应该为测试应用一些花哨的命名约定，但正当的命名可能通过只读失败的测试用例的名称来判断代码的哪一部分被毁坏了。
9、每个测试仅蕴含一个逻辑断言
为了实现仅仅通过读取失败测试的名称就能够判断出谬误的指标，须要的不仅仅是好的名称。一个测试查看也必须限度一些事件。因而，一个好的单元测试应该只蕴含一个逻辑断言，即只查看被测试方法的一个输入 / 副作用。
10、设计你的测试
这是一个元技巧，它涵盖了本文中所有其余技巧以及在这里没有提到的技巧。看待测试要像看待 / 编写代码一样审慎。思考良好的设计准则和指标，如测试代码和生产代码之间的低耦合，以及代码的反复、死代码等。
请记住，一个好的测试套件能够使您在更改和重构代码时感到平安，从而使您的工作更加轻松，而蹩脚的测试套件则会使您痛苦不堪，节约大量的工夫，并使代码简直不可能更改。
以上十个规范不肯定须要全副遵循，可依据团队、集体状况进行选择性取舍。
作者：陈琦，资深麻利测试参谋，作为国内出名项目管理软件——禅道的团队成员，次要负责开源自动化测试治理框架——ZTF 的开发工作。领有十多年的麻利过程实践经验，现致力于测试自动化和 DevOps 相干畛域的实际和钻研。