Mock Objects：缺点和用例

　　现在，我们使用 EasyMockTemplate 重新建立测试：

  @Test public void shouldAddNewEmployee() {
    EasyMockTemplate t = new EasyMockTemplate(mockEmployeeDao) {
      @Override protected void expectations() {
        mockEmployeeDAO.insert(employee);
      }
 
      @Override protected void codeToTest() {
        employeeBO.addNewEmployee(employee);
      }
    };
    t.run();    
  }
 
  @Test public void shouldUpdateEmployee() {
    EasyMockTemplate t = new EasyMockTemplate(mockEmployeeDao) {
      @Override protected void expectations() {
        mockEmployeeDAO.update(employee);
      }
 
      @Override protected void codeToTest() {
        employeeBO.updateEmployee(employee);
      }
    };
    t.run();    
  }
　　EasyMockTemplate可以带来以下优点： 

• 因expectations和codeToTest方法是抽象的，故EasyMockTemplate会强制开发人员指定期望结果和要测试的代码，从而减少程序错误。
• 可以明确区分期望结果和要测试的代码，这使测试更容易理解和维护。
• 避免了代码重复，因为我们不必再去调用replay和verify方法了。

　　您可以从 此处 下载EasyMockTemplate 的最新版本。

Mock测试可能是脆弱的

　　Mock测试属于白盒测试，它需要非常熟悉类的内部知识。这是Mock交互特性的副作用。对方法实现的合理修改可能会破坏使用Mock的测试，即便这种方法的运行结果是相同的。

　　在本例中，EmployeeBO将与EmployeeDAO交互，并使用简单JDBC将员工信息存储于数据库中。假设我们改变了在数据库中存储信息的方式――比如说，将JDBC改为JPA――使用EmployeeJPA替换EmployeeDAO，并在相同的数据库表中存储相同的信息。我们期望已有测试会通过，因为输出（将数据存储在数据库中）没有改变。遗憾的是，我们的测试将以失败告终，因为EmployeeBO和EmployeeDAO之间的交互已经不复存在：现在，EmployeeBO将使用EmployeeJPA在数据库中存储数据，如图2所示。

文章来源于领测软件测试网 https://www.ltesting.net/