望文生义，Groovy/Spock测试框架

单元测试重要不重要？大多数受访者会回答重要；单元测试好不好写？超过一半的受访者会回答不好写；单元测试这种重要却又不好写的设定恐怕会让不少人在使用它时分分钟想暴走。撇开高大上的测试思想、模式不谈，究竟有哪些实际的问题阻碍了我们去写好测试？是不是解决了这些问题就有可能让单元测试变成康庄大道，先让我大开脑洞帮大家分析分析。

Reason1：英文没学好

很多时候当你想好了要怎么实现，这里用一个模式，那里用一个框架的时候，却发现写不了测试，为啥？不知道自己要测的玩意怎么用英语来表达。想用套路却又无处安放——方法名怎么写啊，我该should个啥或者该test个啥啊，我只会简单的大学英语4级的简单句法，对，就那种主语（I/You/He/She/It）+动词（tell/make/use）+宾语+（well/success/fail）的啊。

尴尬

Reason2：框架套路深

Java开发者在单元测试时均会使用mockito或powermock，但mockito和powermock均包含了许多样本代码，导致测试代码变得冗长而难以维护。同时还得注意各种各样的步骤和规则，经常能看到由于误用测试套件而发生的“惨案”，如果没有“老司机”的指引解决问题的周期会变得遥遥无期，因为看着那些让人不好理解（见Reason1）的异常信息绝对让人生无可恋。

生无可恋

也许还能抢救一下

难道就不能整个句法简单（英语4级完全cover）、套路一般的测试框架？这个真可以有，使用Groovy/Spock就可以了。下面通过一个简单例子来展示Groovy/Spock框架，例子中将包含一个service类，负责处理User对象，以及一个数据访问层。

public class User {

    private int id;
    private String name;
    private int age;

    // Accessors omitted
}

接下来是DAO接口：

public interface UserDao {
    public User get(int id);
}

最后是service类：

public class UserService {

    private UserDao userDao;
    
    public UserService(UserDao userDao) {
        this.userDao = userDao;
    }
    
    public User findUser(int id){
        return null;
    }
}

采用Groovy/Spock针对UserService编写测试

class UserServiceTest extends Specification {

    UserService service
    UserDao dao = Mock(UserDao)

    def setup(){
      service = new UserService(dao)
    }

    def "it gets a user by id"(){
      given:
      def id = 1

      when:
      def result = service.findUser(id)

      then:
      1 * dao.get(id) >> new User(id:id, name:"James", age:27)
      result.id == 1
      result.name == "James"
      result.age == 27
    }
}

上述测试代码使用了groovy，这是一种非常类似Java的语言但是它的语法更加轻，例如它不用像Java语言那样，在每句结尾加上分号；它也不需要使用public修饰符，因为public是默认的。上述测试类继承自spock.lang.Specification，这是Spock基类，继承该基类后就可以使用given，when，then等代码块。关键的重点来了：

• 在Spock中创建mock对象非常容易，只需要使用Mock(Class)这样的语句即可。如上所述，mock后的DAO对象被传入userService中。Setup方法会在每个测试方法运行前被执行。

• Groovy的一个显著特点是可以使用字符串文本来命名方法，将这个特点应用在测试方法上就能使得测试方法可以更加容易被阅读和理解（妥妥标准英语4级水平句式）。

这福利如何？绝对是业界良心啊，一举解决两大困扰写好单元测试的难题还不额外增加负担，听着都觉得美，此外Groovy/Spock还有其他的一些好用的特色。

Given, when, then

Spock是一个BDD测试框架，因此对于Spock中涉及的given，when，then样式最简单的理解就是：

Given 给定一些条件，When 当执行一些操作时，Then 期望得到某个结果。如上述测试方法中Given，给定id=1，即测试的变量；而在When中则是被测试方法，如在上述代码中调用findUser()；Then则是断言，即检查被测试方法的输出结果，Then的第一句语句虽然看上去可怕，但实际上却非常容易理解：

1 * dao.get(id) >> new User(id:id, name:"James", age:27)

该行表示了对于mock对象dao的期望值，即期望调用dao.get()方法1次，而“>>”是spock的特色，表示“then return”含义。因此该句翻译过来的意思是：期望调用1次dao.get()方法，当执行该方法后，请返回一个新的User对象。此外在构造方法中使用具名参数也是groovy的另一特点。Then中剩余的代码对result对象进行检查。

望文生义有木有，简单易懂的符号开发人员一看就明白，还不会产生歧义，并且Groovy/Spock还能做得更好：

• 可以命名spock块，例如将given命名为“Some variables”，有助于开发者在测试代码中更加清楚的表达含义

• 当对mock对象方法调用次数不关心时，可以使用_ * mock.method()

• 在then块中可使用下划线来通配方法及类，例如，0 * mock._ 表示期望mock对象的任何方法都未被调用，或0 * . 表示期望任何对象的任何方法都未被调用

• 通常按given，when，then编写测试，但实际上从when开始编写测试会更加容易发现测试需要的given和测试的输出结果(then)

• expect块对于测试不需要对mock对象进行断言的简单方法更加有效

• 当对于传递给mock对象的参数不关注时，可以使用通配符参数

结语

单元测试是为了协助开发者的，而不是起相反作用的，只有有效地降低开发者在单元测试上的成本，才能让单元测试真正地融入每个开发者的行动中，而Groovy/Spock在这方面提供了很多快捷方式来帮助开发者写出更加优雅的单元测试，逐步摆脱编程语言的语法束缚，利用纯粹的书写或口头表达方式，让单元测试成为真正的人人能懂的“望文生义”好代码，真正地成为产品代码的 living docs。