单元测试编写规范

一、简介

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

二、规范细节

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

1、被测试的方法

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

/**
 * 发货申请明细暂不发货
 * 
 * @testcase com.annoroad.ticket.service.ApplyOrderServiceTestCase
 * @param code 编号（UUID）
 * @param updateBy 创建人
 * @param updateByName 创建人名称
 */
@Transactional(rollbackFor = Exception.class)
public void notDelivery(String code, String updateBy, String updateByName) {
    ......
}
1
2
3
4
5
6
7
8
9
10
11
12

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

2、单元测试

1. 方法注释
   包括三个元素：测试目标、场景、期望

    /**
     * 测试目标：要测试的类和方法，例如：com.annoroad.xxx.service.HelloService.sayHello
     * 场景：对要测试的场景进行描述
     * 期望：对期望结果的描述
     */
    @Test
    public void testSayHelloSuccess() {
        ......
    }
   1
   2
   3
   4
   5
   6
   7
   8
   9

2. 方法命名
   针对某个方法的单元测试，可能存在有多个成功，多个失败的场景，针对不同的场景我们会写很多个测试用例，而测试用例的名字我们可以按着如下规则来定义：
   • 成功
     方法命名的格式：test + ${methodName} + Success，例如：testCreateOrderSuccess。如果有多个成功的场景，则可以在末尾添加1、2、3 … N，例如：testCreateOrderSuccess1，testCreateOrderSuccess2，testCreateOrderSuccess3 …

     /**
      * 测试目标：com.annoroad.ticket.service.ApplyOrderService.notDelivery
      * 场景：成功
      * 期望：成功
      */
     @Test
     public void testNotDeliverySuccess() {
         ......
     }
     1
     2
     3
     4
     5
     6
     7
     8
     9

   • 失败
     方法命名的格式：test + ${methodName} + Fail，例如：testCreateOrderFail。如果有多个失败的场景，则可以在末尾添加1、2、3 … N，例如：testCreateOrderFail1，testCreateOrderFail2，testCreateOrderFail3 …

     /**
      * 测试目标：com.annoroad.ticket.service.ApplyOrderService.notDelivery
      * 场景：申请单中明细的状态为暂不发货
      * 期望：抛出 BizException(ResponseCode.APPLY_ORDER_DEVICE_NOT_ALLOW)
      */
     @Test
     public void testNotDeliveryFail1() {
         ......
     }
      
     /**
      * 测试目标：com.annoroad.ticket.service.ApplyOrderService.notDelivery
      * 场景：申请单中明细的状态为已发货
      * 期望：抛出 BizException(ResponseCode.APPLY_ORDER_DEVICE_NOT_ALLOW)
      */
     @Test
     public void testNotDeliveryFail2() {
         ......
     }
      
     /**
      * 测试目标：com.annoroad.ticket.service.ApplyOrderService.notDelivery
      * 场景：不存在与 code 对应的申请单明细
      * 期望：抛出 BizException(ResponseCode.APPLY_ORDER_DEVICE_NOT_EXIST)
      */
     @Test
     public void testNotDeliveryFail3() {
         ......
     }
     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     13
     14
     15
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29

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