2025年单元测试规范文档怎么写(单元测试 规范)

单元测试规范文档怎么写(单元测试 规范)svg xmlns http www w3 org 2000 svg style display none svg

大家好,我是讯享网,很高兴认识大家。



 <svg xmlns="http://www.w3.org/2000/svg" style="display: none;"> <path stroke-linecap="round" d="M5,0 0,2.5 5,5z" id="raphael-marker-block" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0);"></path> </svg> 

讯享网

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


讯享网

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

1、被测试的方法

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

讯享网

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

2、单元测试
  1. 方法注释
    包括三个元素:测试目标、场景、期望
     
  2. 方法命名
    针对某个方法的单元测试,可能存在有多个成功,多个失败的场景,针对不同的场景我们会写很多个测试用例,而测试用例的名字我们可以按着如下规则来定义:
    • 成功
      方法命名的格式:test + \({methodName} &#43; <strong>Success</strong>&#xff0c;例如&#xff1a;<strong>test</strong>CreateOrder<strong>Success</strong>。如果有多个成功的场景&#xff0c;则可以在末尾添加1、2、3 … N&#xff0c;例如&#xff1a;<strong>test</strong>CreateOrder<strong>Success1</strong>&#xff0c;<strong>test</strong>CreateOrder<strong>Success2</strong>&#xff0c;<strong>test</strong>CreateOrder<strong>Success3</strong> …<pre></pre> </li><li>失败<br /> 方法命名的格式&#xff1a;<strong>test</strong> &#43; \){methodName} + Fail,例如:testCreateOrderFail。如果有多个失败的场景,则可以在末尾添加1、2、3 … N,例如:testCreateOrderFail1testCreateOrderFail2testCreateOrderFail3
      讯享网

    制定原因: 这所以这样,主要还是因为团队的英文水平不行,没办法通过方法名很好的描述场景(要不太长、要不看不懂、要不不达意 …)。所以,就不纠结方法如何命名了(这个真的让人头大!!!),直接通过 场景、期望 两个元素来描述这个单元测试用例到底要干啥。


小讯
上一篇 2025-05-06 12:40
下一篇 2025-06-08 12:11

相关推荐

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容,请联系我们,一经查实,本站将立刻删除。
如需转载请保留出处:https://51itzy.com/kjqy/162037.html