大话重构连载15：采用Mock技术完成测试

第五次重构我们引入了数据库的设计，用户信息要从数据库中读取，问候语库存储在数据库中，并支持添加与更新。数据库的引入使自动化测试变得困难了，因为数据状态总是变化着的，而这种变化使得测试过程不能复现，这是我们不愿看到的。因此，我们在设计时将业务与数据库访问分离，形成了UserDao与GreetingRuleDao。此时，我们的设计应当遵从“依赖反转”原则，即将UserDao与GreetingRuleDao设计成接口，并编写它们的实现UserDaoImpl与GreetingRuleDaoImpl。这样设计就为我们Mock掉UserDao与GreetingRuleDao的实现类创造了条件。

这是我们的设计：

图4.3 HelloWorld的设计图

 

为此，我们编写了这样的测试程序：

    private HelloWorld helloWorld = null;
    private GreetingToUserImpl greetingToUser = null;
    private GreetingAboutTimeImpl greetingAboutTime = null;
    private final static List<GreetingRule> GREETING_RULES = getRules();
    
    /**
     * @throws java.lang.Exception
     */
    @Before
    public void setUp() throws Exception {
        helloWorld = new HelloWorld();
        greetingToUser = new GreetingToUserImpl();
        greetingAboutTime = new GreetingAboutTimeImpl();
        helloWorld.setGreetingToUser(greetingToUser);
        helloWorld.setGreetingAboutTime(greetingAboutTime);
    }
    
    /**
     * @throws java.lang.Exception
     */
    @After
    public void tearDown() throws Exception {
        helloWorld = null;
        greetingToUser = null;
        greetingAboutTime = null;
    }

    /**
     * Test method for {@link org...HelloWorld#sayHello(java.util.Date, java.lang.String)}.
     */
    @Test
    public void testSayHelloInTheMorning() {
        final Date now = DateUtil.createDate(2013, 9, 7, 9, 23, 11);
        final long userId = 2013090701;
        
        UserDao userDao = createMock(UserDao.class);
        GreetingRuleDao greetingRuleDao = createMock(GreetingRuleDao.class);
        expect(userDao.loadUser(userId)).andAnswer(new IAnswer<User>(){
            @Override
            public User answer() throws Throwable {
                User user = new User();
                user.setUserId(userId);
                user.setName("鲍晓妹");
                return user;
            }});
        expect(greetingRuleDao.findAllGreetingRules())
        .andAnswer(new IAnswer<List<GreetingRule>>(){
            @Override
            public List<GreetingRule> answer() throws Throwable {
                return GREETING_RULES;
            }});
        replay(userDao);
        replay(greetingRuleDao);
        
        greetingToUser.setUserDao(userDao);
        greetingAboutTime.setGreetingRuleDao(greetingRuleDao);
        
        String result = helloWorld.sayHello(now, userId);
        Assert.assertEquals("Hi, 鲍晓妹. Good morning!", result);
        verify(userDao);
        verify(greetingRuleDao);
    }

 

这段测试程序比较长，但其它部分都是打酱油的，核心是那个testSayHelloInTheMorning()用例，即问候早上好这个用例。userDao与greetingRuleDao是两个接口，我们在实例化它们的时候，并没有去创建它们的实现类，而是用Mock的方式进行创建：

    UserDao userDao = createMock(UserDao.class);
    GreetingRuleDao greetingRuleDao = createMock(GreetingRuleDao.class);

 

随后我们开始定义它们的行为loadUser()与getAllGreetingRules()。在这个测试用例中，我们并不关心它们是怎样去数据库里查询数据并返回的，我们只关心它们是否得到应该得到的参数，并要求它们按照规定返回一个结果：

    final long userId = 2013090701;
    expect(userDao.loadUser(userId)).andAnswer(new IAnswer<User>(){
            @Override
            public User answer() throws Throwable {
                User user = new User();
                user.setUserId(userId);
                user.setName("鲍晓妹");
                return user;
            }});

 

我们希望被测程序在执行的时候调用了userDao.loadUser(userId)，并且调用时传入的参数userId = 2013090701。如果测试过程中传入的参数是这个值，这一项检查点可以通过，否则不能通过。随后我们希望该函数返回“鲍晓妹”这个用户对象。通过Mock程序，我们完全将数据库访问的过程剥离在自动化测试之外，而只是验证它的输入参数，并指定测试所需的返回结果。也就是说数据访问过程被Mock掉，而大大降低了测试难度。

如果UserDao与GreetingRuleDao的Mock程序不能得到规定的参数时，测试就不能通过，这就是说传递给Mock程序的参数也成为了测试程序要验证的一个输出。随后，Mock程序返回规定值，该规定值则成为了被测程序的一个输入。最后，被测程序根据这个输入返回结果，为测试程序所验证，测试结束（如图4.4所示）。

 

图4.4 HelloWorld的自动化测试

图中的BUS层才是我们大量编码，应当自动化测试的部分。既然是测试就是验证怎样的输入，应当得到怎样的输出。Web层向BUS层发出的请求，即调用BUS层某个类的方法，就是测试用例中的一个输入，执行完该方法后的返回值就是测试用例的一个输出。但是，这对输入输出并不是该测试用例的全部。这里经过BUS层处理以后，经过一系列的逻辑判断和数据操作，随后会去调用DAO层进行数据访问操作。调用DAO层时所传递的参数，就是测试用例的另一个输出。图中，从DAO层的输入，到它的输出，这段数据库访问的过程被Mock程序Mock掉了，因为它不在这个用例的测试范围。然后DAO层返回给BUS层一个结果，该结果就是测试用例的另一个输入。接着BUS层会再次对这个返回结果进行处理，最后返回给Web层最终的结果。这就是采用Mock方式进行自动化测试的一个完整流程。

采用自动化测试，测试程序将不再验证后台的数据库是否正确，同时也不再验证前台的Web应用及其前端设备是否正确。在该例中，系统的真正目的是要在前台显示对用户的问候，因此将会有一个Action或Servlet调用HelloWorld：

    Date now = DateUtil.getNow();
    String user = SessionUtil.getCurrentUser(session);
    HelloWorld helloWorld = new HelloWorld();
    String greeting = helloWorld.sayHello(now, user);
    request.setAttribute(“greeting”, greeting);

 

然而，这些程序都不适合自动化测试而应采用手工测试。回顾HelloWorld自动化测试建立的过程我们不难发现，它在设计之初就实现了业务逻辑与Web应用、与数据访问的分离，所以它可以轻易的建立自动化测试。但是，不幸的是，我们大多数的遗留系统在设计之初都没有考虑到这些。因此，我说，在重构之初首先建立自动化测试机制是不现实的，我们只能采用手工测试结合QTP的方式。只有当我们通过重构，使系统架构满足自动化测试的条件之后，自动化测试才可以开展。

毫无疑问，测试与重构形成了一个“鸡生蛋，还是蛋生鸡”的怪圈，成为我们实践系统重构一大拦路虎。本书将在后面详细讨论这个话题（详见第十六章 测试的困境），为你破解这个谜团。

大话重构连载首页：http://www.cnblogs.com/mooodo/p/talkAboutRefactoringHome.html

特别说明：希望网友们在转载本文时，应当注明作者或出处，以示对作者的尊重，谢谢！