单元测试规范文档怎么写（单元测试 规范）



为了统一司内的单元测试编写风格，且让大家无需考虑不重要的事情（无脑按着条条框框执行就好了），专注于写单元测试。基于司内的具体情况，制定了一套简单的《单元测试编写规范》。在这里进行分享，希望能给大家提供一些思路。

该规范针对两个对象，一个是被测试的方法，一个是单元测试。

1、被测试的方法

需要在有测试用例的方法上进行标记，用来提醒维护人在进行代码维护的同时还要持续维护对应的测试用例。我们采用自定义注解 @testcase 来标记当前方法对应的测试用例，如下：

制定原因： 因为司内单元测试用例覆盖度不高，不知道哪个方法有单元测试。将有对应单元测试的方法进行标记，便于未来该方法变更的时候，提醒程序猿本次变更可以依赖单元测试进行验证。

2、单元测试

1. 方法注释
   包括三个元素：测试目标、场景、期望
   
   
   
2. 方法命名
   针对某个方法的单元测试，可能存在有多个成功，多个失败的场景，针对不同的场景我们会写很多个测试用例，而测试用例的名字我们可以按着如下规则来定义：
   • 成功
     方法命名的格式：test + ${methodName} + Success，例如：testCreateOrderSuccess。如果有多个成功的场景，则可以在末尾添加1、2、3 … N，例如：testCreateOrderSuccess1，testCreateOrderSuccess2，testCreateOrderSuccess3 …
     
     
     
   • 失败
     方法命名的格式：test + ${methodName} + Fail，例如：testCreateOrderFail。如果有多个失败的场景，则可以在末尾添加1、2、3 … N，例如：testCreateOrderFail1，testCreateOrderFail2，testCreateOrderFail3 …
     
     
     
   制定原因： 这所以这样，主要还是因为团队的英文水平不行，没办法通过方法名很好的描述场景（要不太长、要不看不懂、要不不达意 …）。所以，就不纠结方法如何命名了（这个真的让人头大！！！），直接通过 场景、期望 两个元素来描述这个单元测试用例到底要干啥。
   
   

版权声明：

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！

转载请注明出处，原文链接：https://www.xkablog.com/te-unit/46714.html