大话重构连载15:采用Mock技术完成测试
程序员文章站
2022-05-05 13:25:56
...
第五次重构我们引入了数据库的设计,用户信息要从数据库中读取,问候语库存储在数据库中,并支持添加与更新。数据库的引入使自动化测试变得困难了,因为数据状态总是变化着的,而这种变化使得测试过程不能复现,这是我们不愿看到的。因此,我们在设计时将业务与数据库访问分离,形成了UserDao与GreetingRuleDao。此时,我们的设计应当遵从“依赖反转”原则,即将UserDao与GreetingRuleDao设计成接口,并编写它们的实现UserDaoImpl与GreetingRuleDaoImpl。这样设计就为我们Mock掉UserDao与GreetingRuleDao的实现类创造了条件。
这是我们的设计:
为此,我们编写了这样的测试程序:
这段测试程序比较长,但其它部分都是打酱油的,核心是那个testSayHelloInTheMorning()用例,即问候早上好这个用例。userDao与greetingRuleDao是两个接口,我们在实例化它们的时候,并没有去创建它们的实现类,而是用Mock的方式进行创建:
随后我们开始定义它们的行为loadUser()与getAllGreetingRules()。在这个测试用例中,我们并不关心它们是怎样去数据库里查询数据并返回的,我们只关心它们是否得到应该得到的参数,并要求它们按照规定返回一个结果:
我们希望被测程序在执行的时候调用了userDao.loadUser(userId),并且调用时传入的参数userId = 2013090701。如果测试过程中传入的参数是这个值,这一项检查点可以通过,否则不能通过。随后我们希望该函数返回“鲍晓妹”这个用户对象。通过Mock程序,我们完全将数据库访问的过程剥离在自动化测试之外,而只是验证它的输入参数,并指定测试所需的返回结果。也就是说数据访问过程被Mock掉,而大大降低了测试难度。
如果UserDao与GreetingRuleDao的Mock程序不能得到规定的参数时,测试就不能通过,这就是说传递给Mock程序的参数也成为了测试程序要验证的一个输出。随后,Mock程序返回规定值,该规定值则成为了被测程序的一个输入。最后,被测程序根据这个输入返回结果,为测试程序所验证,测试结束(如图4.4所示)。
图中的BUS层才是我们大量编码,应当自动化测试的部分。既然是测试就是验证怎样的输入,应当得到怎样的输出。Web层向BUS层发出的请求,即调用BUS层某个类的方法,就是测试用例中的一个输入,执行完该方法后的返回值就是测试用例的一个输出。但是,这对输入输出并不是该测试用例的全部。这里经过BUS层处理以后,经过一系列的逻辑判断和数据操作,随后会去调用DAO层进行数据访问操作。调用DAO层时所传递的参数,就是测试用例的另一个输出。图中,从DAO层的输入,到它的输出,这段数据库访问的过程被Mock程序Mock掉了,因为它不在这个用例的测试范围。然后DAO层返回给BUS层一个结果,该结果就是测试用例的另一个输入。接着BUS层会再次对这个返回结果进行处理,最后返回给Web层最终的结果。这就是采用Mock方式进行自动化测试的一个完整流程。
采用自动化测试,测试程序将不再验证后台的数据库是否正确,同时也不再验证前台的Web应用及其前端设备是否正确。在该例中,系统的真正目的是要在前台显示对用户的问候,因此将会有一个Action或Servlet调用HelloWorld:
然而,这些程序都不适合自动化测试而应采用手工测试。回顾HelloWorld自动化测试建立的过程我们不难发现,它在设计之初就实现了业务逻辑与Web应用、与数据访问的分离,所以它可以轻易的建立自动化测试。但是,不幸的是,我们大多数的遗留系统在设计之初都没有考虑到这些。因此,我说,在重构之初首先建立自动化测试机制是不现实的,我们只能采用手工测试结合QTP的方式。只有当我们通过重构,使系统架构满足自动化测试的条件之后,自动化测试才可以开展。
毫无疑问,测试与重构形成了一个“鸡生蛋,还是蛋生鸡”的怪圈,成为我们实践系统重构一大拦路虎。本书将在后面详细讨论这个话题(详见 第十六章 测试的困境),为你破解这个谜团。
大话重构连载首页:http://fangang.iteye.com/blog/2081995
特别说明:希望网友们在转载本文时,应当注明作者或出处,以示对作者的尊重,谢谢!
这是我们的设计:
图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://fangang.iteye.com/blog/2081995
特别说明:希望网友们在转载本文时,应当注明作者或出处,以示对作者的尊重,谢谢!
上一篇: 蜂蜜桑椹杞子膏,补益气血
下一篇: MyEclipse9.0优化不完全手册