1、单元测试中测试的是类中的方法，对每个类中的方法进行单独测试，测试方法与测试方法之间是独立的不相互依赖的，并且测试方法不能依赖外部的环境。

例如service中依赖dao，这个dao不是真实的，而是通过mock对象产生的，这就是单元测试。

2.集成测试，就是模块与模块之间相互依赖，如果测试service的时候，如果依赖dao，这个dao不是mock产生的，在容器中真实产生的，依赖真实的dao，那么这就是集成测试。

3.spring Test框架中的spring MVC框架，是在web容器外进行单元测试，spring mvc 会模拟用户的请求，模拟用户的httpRequest session等对象完成对web应用的测试。

4、如果在测试的时候，不运行在真实的容器中进行测试，那么在测试所有的类的时候，类中依赖的对象都必须全部是通过mock对象产生。如果是集成测试，运行在容器中，通过spring对对象进行管理，我们就能够引入真实的对象，完成集成测试。

所以一般对于业务层和web我们都进行集成测试，让测试环境运行在容器之中，在web进行集成测试的时候，需要模拟用户的请求访问，这个时候spring mockMVC框架就是模拟用户的请求访问，产生HttpReques等对象，完成web框架的集成测试。

这里强调容器：并不是指tomcat，而是指的是Spring 容器，在单元测试的时候，不应该依赖Spring 容器，换句话说就是用户不应该通过在单元测试的时候启动ApplicationContext容器，在容器中获得真实的bean对象，bean对象应该通过mock对象产生使用junit测试spring框架应用的时候存在下面的问题。

传统的使用junit测试spring框架的程序，都是在setUp方法中 new FileSysytemXMl，来获得Spring容器的上下文，在Spring 容器中手动获得对应的对象，这个对象不是通过mock产生的所以这是集成测试。

上面问题存在一个很严重的问题，按照junit框架的设计原理，在junit中调用一次测试方法，每调用一次测试方法都会重新生成一个测试类实例，上面如果调用3个测试方法，就会生成三个测试类实例。会调用三次setup方法，导致spring容器被初始化多次。如果解决这个问题了，spring TestContext框架已经解决了该问题，提供了Spring 容器的上下文，不会导致Spring 容器被初始化多次。

按照上面的测试代码，如果要实现数据库事务的操作，需要手动编写很多复杂的代码，相当的麻烦，但是使用Spring TestContext框架，能够让我们很好的使用事务管理。

1. 为Controller编写测试，不需要应用服务器环境。

2. 为Service编写测试，不需要应用服务器环境。

Spring为我们提供了一个测试套件Spring-test，与JUnit结合，可以在运行测试时启动IoC容器测试Service，数据库，也可以在脱离web容器的环境下模拟http请求测试Controller，甚是给力。

测试Controller

当我们编写完一个Controller后，常规的测试方式就是部署运行应用，然后观察运行效果。如果想要编写测试，也要用Mock对象模拟请求参数，模拟HttpSession，特别麻烦。现在spring-test为我们提供了一个更加优雅的测试方式。例如，要测试下面的Controller: