《单元测试的艺术》读书笔记----测试代码的最佳实践

• 测试层次和组织

        1、在自动化每日构建中运行单元测试和集成测试，如使用持续集成工具自动化构建；

        2、基于速度和类型布局测试：

        根据运行测试所花费的时间很容易就能区分集成测试和单元测试，把集成和单元测试分开放置，放在不同的目录，指定单元测试和集成测试运行的频率。

        3、确保测试时源代码管理的一部分，共同放在版本管理器进行管理。

        4、将测试类映射到被测试代码

        创建测试类时，应该怎样组织和放置它们呢？我们希望可以找到一个项目的所有相关测试，一个类的所有相关测试，一个方法的所有相关测试。我们可以采用以下方式：

        （1）测试类和被测试类放到同一个项目内；

        （2）测试类和被测试类尽量保持相同或相似的包层次；

        （3）针对同一个被测试方法的多个测试方法命名，可以采用如userLoginTest_Success，userLoginTest_Fail等。

       5、构建测试API，如使用测试类继承模式，创建测试工具类等；

 

• 优秀单元测试的支柱

        1、编写可靠的测试

      （1）决定何时删除或修改测试

        单元测试何时会执行失败？

        产品缺陷，不必修改测试，只需修复产品缺陷；

        测试缺陷，需要修复测试；

        产品语义或API变更，使用方式改变了，需要修改测试；

        重命名含义不清的测试，重构不可读的测试。

        删除重复测试。

        （2）避免测试中的逻辑

        如果单元测试包含了switch、if、else、foreach、for、while等语句就说明你的测试里包含了不应有的逻辑。

        如果需要复杂大型测试，如多线程测试，你应该在标明为集成测试的包里编写这种测试。

        如下测试代码也包含了不应有的逻辑，无意中重复了产品代码的逻辑user + greeting，        

public void addString(){
        String user = "USER";
        String greeting = "GREETING";
        String actual = MessageBuilder.Build(user, greeting);

        assertEqual(user + greeting, actual);
}

 

        改成如下代码就消除了引入逻辑：

public void addString(){
        String user = "USER";
        String greeting = "GREETING";
        String actual = MessageBuilder.Build(user, greeting);

        assertEqual("USER GREETING", actual);
}

 

        （3）只测试一个关注点

        一个测试方法里保持只有一个断言，我们就更容易诊断出了什么问题。

        （4）把单元测试和集成测试分开

        单元测试很容易运行，集成测试很可能失败，如果不够稳定，开发人员就会跳过所有测试，无法发挥单元测试的作用。

        （5）用代码审查确保代码覆盖率

        如果没有做代码审查，代码覆盖率统计的结论没有说服力。因为开发人员可能在测试方法里不写一个断言，测试总能通过。

        代码审核有助于提升团队的技术水平，还可以创造出可读、高质量、能够持续使用多年的代码，并使你充满自信。

 

        2、编写可维护的测试

        （1）测试私有或受保护的方法

        使方法成为公共方法；

        把方法抽取到新类；

        使方法成为静态方法。

 

        （2）去除重复代码

        抽取辅助方法去除重复代码。

        使用@Before或者@After去除重复代码；

 

        （3）已可维护的方法使用@Before

        局限性：

        @Before方法只用于需要进行初始化工作时；

        @Before方法应该只包含适用于当前测试类中所有测试的代码，否则这个方法会更难以阅读和理解。

        尽量不用@Before方法，而封装辅助初始化方法，每个测试方法手动调用。这样增加代码可读性。

 

        （4）实施测试隔离

        定义：一个测试应该总是能独立运行，不依赖于任何其他测试。

        测试隔离的臭味道：

        强制的测试顺序：测试需要特定的顺序执行，或者来自其他测试结果的信息；

        隐藏的测试调用：测试调用其他测试；

        共享状态损坏：测试共享内存里的状态，却没有回滚状态；

        外部共享状态损坏：集成测试共享资源，却没有回滚资源；

 

        （5）避免对不同关注点多次断言       

@Test
public void CheckVariousUsmResult(){
        assertEqual(3, sum(1001, 1, 2));
        assertEqual(3, sum(1, 1001, 2));
        assertEqual(3, sum(1, 2, 1001));
}

 

        以上单元测试使用了三个简单的断言，进行了三个不同的子功能测试，希望能节省一些时间。这样做法有什么问题呢？如果断言失败，会抛出异常，后续的断言将得不到执行，即后续的功能得不到测试。但这种情况下，即便一个断言失败了，你还是会希望知道其他的断言结果。

        你可以才起别的方式实现这个测试：

        给每个断言创建一个单独的测试；

        使用参数化测试（.Net支持，Java目前好像不支持）；

        把断言放在一个try-catch块中。

 

        （6）对一个对象的多个状态的比较时，有两种方式：

        方法一、多断言方式        

@Test
public void compare(){
        String userName = "zhangf";
        String realName = "张飞";
        String id = "1001";
        User user = new User(id, userName, realName);
 
        assertEqual(id, user.getId());
        assertEqual(userName, user.getUserName());
        assertEqual(realName, user.getRealName());
}

 

         方法二、单个断言方式，toString()比较

@Test
public void compare(){
        String userName = "zhangf";
        String realName = "张飞";
        String id = "1001";
        User user = new User(id, userName, realName);
          assertEqual("id:"+id+",userName:"+userName+",realName:"+realName, user.toString());
}

 

         第一种方式让人看起来以为对多个功能做测试，可读性差，第二种方式可读性强。推荐第二种方式。

 

        （7）避免过度指定

        过度指定是对被测试单元如何实现其内部行为进行了假设，而不只是检查其最终行为的正确性。

        主要有以下几种情况：

        测试对一个被测试对象的春内部状态进行了断言；

        测试使用了多个模拟对象；

        测试在需要存根时使用模拟对象；

        测试在不必要的情况下指定顺序或使用了精确匹配。如对返回的字符串进行精确匹配断言，而实际只需对字符串的一部分做断言就可以了，我们可以不适用String.equal()，而使用String.contains()。

 

        3、编写可读的单元测试

        （1）单元测试命名

        测试方法名包括三部分：被测试方法名，测试场景，预期行为。

        如测试用户登录，场景是多次登陆后要求使用验证码，预期行为是密码错误而失败，可命名为void userLogin_requirePictureNum_fail(){...}

 

        （2）变量命名

        合理的命名变量，可以确保阅读测试的人容易理解你要验证什么。因为单元测试不仅起到测试的作用，还是作为API的一种文档。

        不好的命名如魔法数字，assertEqual(-100, result)，无法看出-100是什么意义，将-100赋值给一个富含表达性命名的变量，如" COULD_NOT_READ_FILE = -100；"，然后用变量做equal，则更容易理解断言的目的。

 

        （3）有意义的断言

          尽量不要编写自己的定制断言信息，如果必须编写，请命名清楚明白。

 

        （4）断言和操作分离

         反例：

         assertEqual(COULD_NOT_READ_FILE, log.GetLineCount("aaa.txt"))   

         正例：

        int result = log.GetLineCount("aaa.txt"); 

        assertEqual(COULD_NOT_READ_FILE, result);

 

        （5）@Before和@After

         这两个方式经常被滥用，以至于方法完全不可读。

        一种滥用的情况：在@Before中准备存根和模拟对象，导致阅读测试的人意识不到测试中使用了模拟对象，也不知道对象的预期值是什么。

        如果由测试方法自己直接设置初始化模拟对象，设置所有的预期值，测试可读性会更好。

 

        要点：测试要随着被测试系统一同成长和变化。