在过去的职业生涯里，我经常发现有些人不写测试代码，而他们声称不写的理由是无法轻易地写出覆盖多个不同模块的测试用例。好吧，我相信他们中的大部分要么是缺乏一些比较易掌握的技术手段，要么就是没时间来把它搞清楚，毕竟工作中总会有进度之类的各种压力。因为不知道该如何测试，所以就经常忽略集成测试，由此带来的问题就是越来越糟糕的软件、越来越多的BUG和更加失望的客户。所以我想分享一些个人的经验，揭开集成测试神秘的面纱。

如何对基于Spring的工程更好地进行集成测试
使用工具: Spring, JUnit, Mockito
想象有这样一个Spring工程，它集成了一些外部服务，例如，一些银行的web服务。那么，为这个工程写测试用例以及在持续集成系统中完成这些测试时所遇到的问题基本都差不多：
1.每次测试都会有交易进行，每次交易都需要付出金钱成本，这些成本最终由客户承担；
2.测试时发出的过多的请求有可能被认为是恶意请求，可能造成在银行的账户被封，后果是测试失败；
3.当使用非生产环境进行测试时，测试结果并不十分可靠，同样，后果是测试失败。
通常情况下，你对单个类进行测试的时候，问题很容易解决，因为你可以虚拟一些外部服务来供调用。但是当对整个巨大的业务流程进行测试的时候，意味你需要对多个部件进行测试，这时，需要你将这些部件都纳入到Spring容器中进行管理。所幸，Spring包含了非常优秀的测试框架，允许你将来自生产环境配置文件中的bean注入到测试环境中，但是对那些被调用的外部服务，需要我们自己去写模拟实现。一般人第一反应可能是在测试的setUp阶段对由Spring注入的bean进行重新注入（修改），但是这种方法需要再仔细考虑一下。

警告：通过这种方式，你的测试代码打破了容器自身的行为，所以没法保证在真实的环境中也如你测试的结果一样。
事实上，我们无需先实现模拟类然后再把它重新注入到所需的bean中，我们可以让Spring帮助我们一开始就注入模拟类。让我们用代码演示一下。
示例工程包含一个名为BankService的类，代表调用的外部服务，一个名为UserBalanceService的类，它会调用BankService。UserBalanceService实现的非常简单，仅仅完成将余额从String向Double类型的转换。
BankService.java的源码：

public interface BankService { String getBalanceByEmail(String email);}

BankServiceImpl.java的源码：

public class BankServiceImpl implements BankService { @Override public String getBalanceByEmail(String email) { throw new UnsupportedOperationException("Operation failed due to external exception"); }}

UserBalanceService.java的源码：

interface UserBalanceService { Double getAccountBalance(String email);}

UserBalanceServiceImpl.java的源码：

public class UserBalanceServiceImpl implements UserBalanceService { @Autowired private BankService bankService; @Override public Double getAccountBalance(String email) { return Double.valueOf(bankService.getBalanceByEmail(email)); }}

然后是Spring的XML配置文件，添加所需要的bean声明。
applicationContext.xml的源代码：

<?xml version="1.0" encoding="UTF-8"?><beans xmlns="http:///article/spring-test-is-easy.html
英文原文：Test Me If You Can #1 (Spring Framework)
翻译作者：码农网 – Sandbox Wang

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持。