你有木有遇到过这种情况,在为一个复杂业务方法写单个单元测试时,你需要做一大堆初始化工作,主要是各种service,你也可以直接把总个容器初始化(如果你使用spring等容器的话),如果项目比较大,运行单个测试,得等上几十秒,你hold住吗,可以参照我的方法进行加速(http://mingliang-luo.iteye.com/blog/1258830);
现在就复杂业务方法写单元测试给出一个解决方案:我采用的是【 继承 + easyMock 】,也可以使用【easyMock class + easyMock】;
一个复杂业务方法内,会调用此类中很多的方法,而你的测试又与之无关,这时,你可以使用继承,直接重写那个方法,那么,这个方法内的初始化工作就不需要做了,当然,你也可以使用【easyMock class】重写;
但如果不是调用此类的方法,而是调用其它service中的方法,那你可以直接使用easyMock代替真实的service;
采用这种方式后,你就可以快速编写这种复杂业务逻辑的测试了,并且它可以运行得很快。
下面是我的一个测试,仅供参考:
static MemberService memberService; //需要测试的方法
static SqlSession sqlSession;
@BeforeClass
public static void beforeClass() throws Exception{
sqlSession = SessionFactory.getSqlSession();
MemberServiceImpl memberServiceImpl = new MemberServiceImpl();
MemberDao memberDao = new MemberDao();
memberDao.setMemberMapper((MemberMapper)SessionFactory.getMapper(MemberMapper.class, sqlSession));
memberServiceImpl.setMemberDao(memberDao);
memberService = memberServiceImpl;
ReturnFreeToCustomerByFirstRefundOrChangeTest re = new ReturnFreeToCustomerByFirstRefundOrChangeTest();
re.setMemberService(memberServiceImpl);
changOrRefundService = re;
}
//第一次退换货,返运费,15元
@Test
public void testReturnFreeToCustomer1th() throws Exception{
ChangOrRefundAssistant cra = new ChangOrRefundAssistant();
cra.setOrderCd("110927001086NT");
cra.setRefundType(NoneyReturnedConstants.REFUNDTYPE_TH);
Order order = new Order();
order.setOrderCd(cra.getOrderCd());
order.setMemberId(239l);
Float account = memberService.queryAccountBalanceByMemberId(order.getMemberId());
//无关的service
OrderCCService orderCCService = createMock(OrderCCService.class);
orderCCService.returnedInventory(EasyMock.<String>anyObject(), EasyMock.<List<OrderItem>>anyObject());
expect(orderCCService.genOrderLog(EasyMock.<PublicLog>anyObject())).andReturn(1);
expect(orderCCService.loadOrdertByCd(EasyMock.<String>anyObject())).andReturn(order);
replay(orderCCService);
changOrRefundService.setOrderCCService(orderCCService);
//退货
changOrRefundService.refundByWarehouseRMI(cra);
sqlSession.clearCache();
Float accountAfter = memberService.queryAccountBalanceByMemberId(order.getMemberId());
//[帐户增加15元]
assertEquals(15, accountAfter - account, 0.001);
List<AccountLog> logs = memberService.queryAccountLogs(order.getMemberId());
AccountLog lastLog = logs.get(0);
//[存入] [15元] [退换货返运费,订单为xxxxxx]
assertEquals(Constants.MBS_ACCOUNT_TRADE_TYPE_1, lastLog.getTradeType());
assertEquals(15, lastLog.getAmount(), 0.001);
assertTrue(lastLog.getNote().startsWith("退换货返运费"));
assertTrue(lastLog.getNote().contains(order.getOrderCd()));
}//下面的全是refundByWarehouseRM会调用的方法,不关心,直接pass
public ChangOrRefund queryChgOrRefdByOrderId(Long orderId) throws Exception{
return new ChangOrRefund();
}
public List<ChangOrRefundDetail> loadChangOrRefundDetailByChgId(Long id)throws Exception {
return new ArrayList<ChangOrRefundDetail>();
}
public List<OrderItem> genOrderItemByRefund(List<ChangOrRefundDetail> lstDetails,Long orderId)throws Exception{
return null;
}
public void updateOrderItemByWhouse(Long orderItemID,String refundType) throws Exception{
}
public void deductInventoryByChange(String channelCode,List<ChangOrRefundDetail> lstChgItem) throws Exception{
}
public void updateOrderByWH(ChangOrRefundAssistant changOrRefundAssistant,Order order) throws Exception{
}
分享到:
相关推荐
随着html5的普及和客户端脚本引擎的强大,之前由后端进行的页面渲染和部分业务逻辑逐渐移至到前端,照成前端逻辑和代码迅速复杂化。如果没有一款合适的单元测试工具保证前端单元模块的正确功能,对后期的代码调试和...
以国内互联网的开发节奏,在前端业务项目中全面覆盖单元测试有时显得不太可行,主要是因为以下这些绊脚石: UI交互复杂,路径难以覆盖全面 工期紧,开发对实践TDD,BDD所带来的长远效益没有信心 产品经理们时...
这样就可以对应用程序逻辑进行单元测试,而无需实际运行对于测试目的来说是不切实际或不可能的SDK代码。用法要使用此模拟库,只需将其包含在自定义测试HTML文件中的脚本标签中,或使用Karma注入(这是一个更好的...
测试驱动自动生成程序基于PSD描述,全自动构建驱动被测程序运行的所有参数,必须的全局变量,并可根据复杂变量的层级结构产生结构化的测试驱动程序,可以节省大量的单元测试用例的编写时间。 (3) 测试数据自动生成...
1.业务逻辑在现在的应用中,复杂的业务逻辑会带来大量的代码量,同时如果业务逻辑进行 谈自动化测试 软件测试 曾经做过很长一段时间的自动化测试‘积累了一些相关的东西。感觉自动化测试现在也是处于一个变化的...
一部分原因是其中都是内部实现,可以把握住输入,令一部分原因是这段实现主要是各种交互,而没有复杂的业务逻辑。我个人满足于单元测试而不是测试驱动开发,但如果您是使用测试驱动开发(TDD)甚至传说中的BDD来实现...
测试驱动自动生成程序基于PSD描述,全自动构建驱动被测程序运行的所有参数,必须的全局变量,并可根据复杂变量的层级结构产生结构化的测试驱动程序,可以节省大量的单元测试用例的编写时间。 (3) 测试数据自动...
相同的操作,不同产品线的业务逻辑不同,例如下单,横向来说,不同产品线、不同类型的组合有几十种业务逻辑分支,纵向说,不同产品线所需步骤也不相同,这种情况下代码如何组织? 3、业务需求多,往往一个需求过来要...
您想要哪种类型的缆车通行证,您的年龄以及您想要滑雪的具体日期,都有一些复杂的逻辑。有一项新功能要求,即能够获得多个升降机通行证的价格,而不仅仅是一个。目前,仅对单张通行证实行定价,但不幸的是,所设计的...
软件测试规范 目 录 一.概述 ................................................................................................................................................ 13 附录一 单元测试报告 ......
3. 2 单元测试 3. 2. 1 单元测试的考虑 3. 2. 2 单元测试的过程 3. 3 集成测试 3. 3. 1 非增式测试 3. 3. 2 增式测试 3. 3. 3 不同集成测试策略的比较 3. 4 确认测试 3. 4. 1 确认测试准则 3. 4. 2 配置...
判定表方法:明确业务逻辑,简化复杂场景的测试设计。 因果图法:直观表示输入与输出的关系,预测潜在问题。 白盒测试部分: 逻辑覆盖技术:从语句到基本路径,全方位覆盖代码逻辑。 语句覆盖:确保每条语句至少...
而系统内部复杂的业务逻辑主要通过JavaBean的组件(Component)实现,JavaBean组件在WWW服务器上运行,通过JSP返回到客户浏览器。通过表现逻辑与业务逻辑的分离,使网页内容简洁,系统的可维护性和可扩充性增强。在...
在每个公司的系统中,总有一些拥有复杂业务逻辑的系统,这些系统承载着核心业务逻辑,几乎每个需求都和这些核心业务有关,这些核心业务业务逻辑冗长,涉及内部逻辑运算,缓存操作,持久化操作,外部资源调取,内部...
AMAZONSERVER_US亚马逊订单下载 ...流程图虽然包含了所有的业务逻辑和模块元素,但并未对它们归类,这使得我们在开发的逻辑里不得不包含所有的业务,逻辑复杂,耦合增大,难以维护和测试。我们将流程归类,如下图所示。
在本阶段,我们主要验证每⼀个处理节点的业务逻辑是否正确, 并验证在多个运⾏后,确保: 1. Map Reduce过程⼯作正常 2. 数据聚合、分离规则已经实现 3. 数据key-value关系已正确⽣成 4. 验证经过map reduce后数据的...
当测试脚本有成百的代码行,验证点,分支的逻辑,错误处理,参数和数据在多个已录制的业务流程之间的相关性时,调试并且解决测试脚本中的问题变得特别的乏味和难以处理。对于调试那些复杂且又冗长的测试脚本,一个...
清洁建筑示例 这是一个示例,说明如何构建可扩展和可测试的应用程序。 该应用程序包含持久性数据访问,业务逻辑和公共数据剩余api。 每一层都将复杂性抽象化,并对其边界进行了测试。 类图
4. 在测试经理的指导下,掌握较深层次的测试方法、测试技术和较复杂的业务流程。 测试员 主要职责: 1. 在测试经理的安排和指导下,编写测试用例; 2. 在测试经理的安排和指导下,完成“执行测试”的工作; 3. 在...
业务逻辑都写在视图逻辑层,但是有苦于没有办法将业务代码剥离 代码越来越臃肿不堪 对老代码不敢碰,会影响很多业务逻辑 为什么借鉴redux 用为redux是框架无关的,所以具有更好的可移植性,当然我这里在内部还是做了...