测试是开发的一个非常重要的方面，可以在很大程度上决定一个应用程序的命运。良好的测试可以在早期捕获导致应用程序崩溃的问题，但较差的测试往往总是导致故障和停机。
三种主要类型的软件测试：单元测试，功能测试和集成测试
软件开发测试的类型
单元测试用于测试各个代码组件，并确保代码按照预期的方式工作。单元测试由开发人员编写和执行。大多数情况下，使用JUnit或TestNG之类的测试框架。测试用例通常是在方法级别写入并通过自动化执行。
集成测试检查系统是否作为一个整体而工作。集成测试也由开发人员完成，但不是测试单个组件，而是旨在跨组件测试。系统由许多单独的组件组成，如代码，数据库，Web服务器等。集成测试能够发现如组件布线，网络访问，数据库问题等问题。
功能测试通过将给定输入的结果与规范进行比较来检查每个功能是否正确实现。通常，这不是在开发人员级别的。功能测试由单独的测试团队执行。测试用例基于规范编写，并且实际结果与预期结果进行比较。有若干工具可用于自动化的功能测试，如Selenium和QTP。
如前所述，单元测试可帮助开发人员确定代码是否正常工作。在这篇博文中，我将提供在Java中单元测试的有用提示。
使用框架来用于单元测试
Java提供了若干用于单元测试的框架。TestNG和JUnit是最流行的测试框架。JUnit和TestNG的一些重要功能：
- 易于设置和运行。
- 支持注释。
- 允许忽略或分组并一起执行某些测试。
- 支持参数化测试，即通过在运行时指定不同的值来运行单元测试。
- 通过与构建工具，如Ant，Maven和Gradle集成来支持自动化的测试执行。
- EasyMock是一个模拟框架，是单元测试框架，如JUnit和TestNG的补充。EasyMock本身不是一个完整的框架。它只是添加了创建模拟对象以便于测试的能力。例如，我们想要测试的一个方法可以调用从数据库获取数据的DAO类。在这种情况下，EasyMock可用于创建返回硬编码数据的MockDAO。这使我们能够轻松地测试我们意向的方法，而不必担心数据库访问。
谨慎使用测试驱动开发！
测试驱动开发（TDD）是一个软件开发过程，在这过程中，在开始任何编码之前，我们基于需求来编写测试。由于还没有编码，测试最初会失败。然后写入最小量的代码以通过测试。然后重构代码，直到被优化。
目标是编写覆盖所有需求的测试，而不是一开始就写代码，却可能甚至都不能满足需求。TDD是伟大的，因为它导致简单的模块化代码，且易于维护。总体开发速度加快，容易发现缺陷。此外，单元测试被创建作为TDD方法的副产品。
然而，TDD可能不适合所有的情况。在设计复杂的项目中，专注于最简单的设计以便于通过测试用例，而不提前思考可能会导致巨大的代码更改。此外，TDD方法难以用于与遗留系统，GUI应用程序或与数据库一起工作的应用程序交互的系统。另外，测试需要随着代码的改变而更新。
因此，在决定采用TDD方法之前，应考虑上述因素，并应根据项目的性质采取措施。
测量代码覆盖率
代码覆盖率衡量（以百分比表示）了在运行单元测试时执行的代码量。通常，高覆盖率的代码包含未检测到的错误的几率要低，因为其更多的源代码在测试过程中被执行。测量代码覆盖率的一些最佳做法包括：
使用代码覆盖工具，如Clover，Corbetura，JaCoCo或Sonar。使用工具可以提高测试质量，因为这些工具可以指出未经测试的代码区域，让你能够开发开发额外的测试来覆盖这些领域。
每当写入新功能时，立即写新的测试覆盖。
确保有测试用例覆盖代码的所有分支，即if / else语句。
高代码覆盖不能保证测试是完美的，所以要小心！
下面的 concat 方法接受布尔值作为输入，并且仅当布尔值为true时附加传递两个字符串：
stringUtil类的方法
public String concat(boolean append, String a,String b) {
String result = null;
If (append) {
result = a + b;
}
return result.toLowerCase();
}
以下是上述方法的测试用例：
@Test
public void testStringUtil() {
String result = stringUtil.concat(true, “Hello “, “World”);
System.out.println(“Result is “+result);
}
在这种情况下，执行测试的值为true。当测试执行时，它将通过。当代码覆盖率工具运行时，它将显示100%的代码覆盖率，因为 concat 方法中的所有代码都被执行。但是，如果测试执行的值为false，则将抛出 NullPointerException 。所以100%的代码覆盖率并不真正表明测试覆盖了所有场景，也不能说明测试良好。
尽可能将测试数据外部化
在JUnit4之前，测试用例要运行的数据必须硬编码到测试用例中。这导致了限制，为了使用不同的数据运行测试，测试用例代码必须修改。但是，JUnit4以及TestNG支持外部化测试数据，以便可以针对不同的数据集运行测试用例，而无需更改源代码。
下面的 MathChecker 类有方法可以检查一个数字是否是奇数：
public class MathChecker {
public Boolean isOdd(int n) {
if (n%2 != 0) {
return true;
} else {
return false;
}
}
}
以下是MathChecker类的TestNG测试用例：
public class MathCheckerTest {
private MathChecker checker;
@BeforeMethod
public void beforeMethod() {
checker = new MathChecker();
}
@Test
@Parameters("num")
public void isOdd(int num) {
System.out.println("Running test for "+num);
Boolean result = checker.isOdd(num);
Assert.assertEquals(result, new Boolean(true));
}
}
以下是testng.xml（用于TestNG的配置文件），它具有要为其执行测试的数据：
< class="hljs xml"><?xml version="1.0" encoding="UTF-8"?>
<suite name="ParameterExampleSuite" parallel="false">
<test name="MathCheckerTest">
<classes>
<parameter name="num" value="3"></parameter>
<class name="com.stormpath.demo.MathCheckerTest"/>
</classes>
</test>
<test name="MathCheckerTest1">
<classes>
<parameter name="num" value="7"></parameter>
<class name="com.stormpath.demo.MathCheckerTest"/>
</classes>
</test>
</suite>
可以看出，在这种情况下，测试将执行两次，值3和7各一次。除了通过XML配置文件指定测试数据之外，还可以通过DataProvider注释在类中提供测试数据。
与TestNG类似，测试数据也可以外部化用于JUnit。以下是与上述相同MathChecker类的JUnit测试用例：
@RunWith(Parameterized.class)
public class MathCheckerTest {
private int inputNumber;
private Boolean expected;
private MathChecker mathChecker;
@Before
public void setup(){
mathChecker = new MathChecker();
}
// Inject via constructor
public MathCheckerTest(int inputNumber, Boolean expected) {
this.inputNumber = inputNumber;
this.expected = expected;
}
@Parameterized.Parameters
public static Collection<Object[]> getTestData() {
return Arrays.asList(new Object[][]{
{1, true},
{2, false},
{3, true},
{4, false},
{5, true}
});
}
@Test
public void testisOdd() {
System.out.println(“Running test for:”+inputNumber);
assertEquals(mathChecker.isOdd(inputNumber), expected);
}
}
可以看出，要对其执行测试的测试数据由getTestData（）方法指定。此方法可以轻松地修改为从外部文件读取数据，而不是硬编码数据。
这样避免了重复写测试框架的麻烦,只需要外部文件中读取测试数据即可.
使用断言而不是Print语句
许多新手开发人员习惯于在每行代码之后编写System.out.println语句来验证代码是否正确执行。这种做法常常扩展到单元测试，从而导致测试代码变得杂乱。除了混乱，这需要开发人员手动干预去验证控制台上打印的输出，以检查测试是否成功运行。更好的方法是使用自动指示测试结果的断言。
下面的 StringUti 类是一个简单类，有一个连接两个输入字符串并返回结果的方法：
public class StringUtil {
public String concat(String a,String b) {
return a + b;
}
}
以下是上述方法的两个单元测试：
@Test
public void testStringUtil_Bad() {
String result = stringUtil.concat("Hello ", "World");
System.out.println("Result is "+result);
}
@Test
public void testStringUtil_Good() {
String result = stringUtil.concat("Hello ", "World");
assertEquals("Hello World", result);
}
testStringUtil_Bad将始终传递，因为它没有断言。开发人员需要手动地在控制台验证测试的输出。如果方法返回错误的结果并且不需要开发人员干预，则testStringUtil_Good将失败。
一开始，是通过输出结果判断输出结果是否正确来判断，console虽然输出是true，false 和预期的是一样，但是junit显示都是成功的，并没有出现报错，达不到使用junit测试的效果。
junit 出现failures 和 errors 的情况：
Failure指的是由于预期的结果与实际运行的测试的结果不同而导致的，例如当使用assertEquals()或其它assertXXX()方法断言失败时，就会报出Failure，如果发现Faulure，你就要去检查你的测试方法或者是被测试方法中编写的逻辑是否有误。
Error指的是编写程序时没有考虑到的问题。在执行测试的断言之前，程序就因为某种类型的意外而停止，比喻说我们在操作数组的时候，因为存取超出索引会引发ArrayIndexOutOfBoundsException，这个时候程序就会报出Error，程序将无法运行下去，提前结束，这个时候你要检查被测试方法中是不是有欠缺考虑到地方。
Junit的断言方法：
assertEquals 和 assertTrue 区别
相同之处：都能判断两个值是否相等
assertTrue 如果为true，则运行success，反之Failure
assertEquals 如果预期值与真实值相等，则运行success，反之Failure
不同之处：
assertEquals 运行Failure会有错误提示，提示预期值是xxx，而实际值是xxx。容易调式
assertTrue 没有错误提示
两种方法都可以判断，一般建议使用assertEquals 容易调试
构建具有确定性结果的测试
一些方法不具有确定性结果，即该方法的输出不是预先知道的，并且每一次都可以改变。例如，考虑以下代码，它有一个复杂的函数和一个计算执行复杂函数所需时间（以毫秒为单位）的方法：
public class DemoLogic {
private void veryComplexFunction(){
//This is a complex function that has a lot of database access and is time consuming
//To demo this method, I am going to add a Thread.sleep for a random number of milliseconds
try {
int time = (int) (Math.random()*100);
Thread.sleep(time);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
public long calculateTime(){
long time = 0;
long before = System.currentTimeMillis();
veryComplexFunction();
long after = System.currentTimeMillis();
time = after - before;
return time;
}
}
在这种情况下，每次执行 calculateTime 方法时，它将返回一个不同的值。为该方法编写测试用例不会有任何用处，因为该方法的输出是可变的。因此，测试方法将不能验证任何特定执行的输出。
除了正面情景外，还要测试负面情景和边缘情况
通常，开发人员会花费大量的时间和精力编写测试用例，以确保应用程序按预期工作。然而，测试负面测试用例也很重要。负面测试用例指的是测试系统是否可以处理无效数据的测试用例。例如，考虑一个简单的函数，它能读取长度为8的字母数字值，由用户键入。除了字母数字值，应测试以下负面测试用例：
用户指定非字母数字值，如特殊字符。
用户指定空值。
用户指定大于或小于8个字符的值。
类似地，边界测试用例测试系统是否适用于极端值。例如，如果用户希望输入从1到100的数字值，则1和100是边界值，对这些值进行测试系统是非常重要的。
本文转载自：http://www.linuxprobe.com/write-java-test.html
JUnit是由 Erich Gamma 和 Kent Beck 编写的一个回归测试框架（regression testing framework）。Junit测试是程序员测试，即所谓白盒测试，因为程序员知道被测试的软件如何（How）完成功能和完成什么样（What）的功能。Junit是一套框架，继承TestCase类，就可以用Junit进行自动测试了。
推荐这个文章 http://hao.jobbole.com/junit/
官方手册： https://junit.org/junit4/cookbook.html
API手册： https://junit.org/junit4/javadoc/latest/
新手指南： https://github.com/junit-team/junit4/wiki/Getting-started
关于JAVA springMVC开发中的常用测试模块
在java开发中，WEB端开发会用到框架来开发，在开发的过程中要不断的通过重启服务器来修改配置及页面访问控制，这给系统造成很大的负担，那么如何通过不启动服务器就可以完成页面访问测试呢？
在常用的测试框架中Junit就提供了很好的功能API–MockMVC。
基于RESTful风格的SpringMVC的测试，我们可以测试完整的Spring MVC流程，即从URL请求到控制器处理，再到视图渲染都可以测试。
目前主流的Web MVC框架除了Struts之外就是SpringMVC，不过要想灵活运用SpringMVC来应对大多说的web开发除了必须掌握其配置和原理外还需要会测试。在Spring3.2版本之前测试一般都是直接new控制器注入依赖进行判断返回，但无法测试基础配置参数如拦截器、数据绑定、类型转换等等。（struts2只需要了解即可，现在市面上基本不用Struts2作为开发框架了，难以维护不过也不排除一些老项目的维护）
springboot开发中只需要在测试模块写：
@RunWith(SpringJUnit4ClassRunner.class)
//使用 Spring-Test 框架;在使用所有注释前必须使用@RunWith(SpringJUnit4ClassRunner.class),让测试运行于Spring测试环境。
@WebAppConfiguration()
//由于是web项目，Junit需要模拟ServletContext，需要给测试类加上@WebAppConfiguration注解
//@WebAppConfiguration是一级注释，用于声明一个ApplicationContext集成测试加载WebApplicationContext。作用是模拟ServletContext
这两个注解即可使用MockMVC来完成模拟测试。（如果不用Springboot框架只用springMVC的话，那就要麻烦些）
具体参考：https://baijiahao.baidu.com/s?id=1578508515485033349&wfr=spider&for=pc
http://www.cnblogs.com/lyy-2016/p/6122144.html
如果不是springboot项目的话
需要加@ContextConfiguration这个注解，因为springboot的配置文件都在中央配置文件里，而springMVC的配置文件则是分散的，所以这就需要声明要测试的组件的配置文件在哪里。一下我归纳的都是springboot项目的MockMVC测试。
那么我们该如何使用MockMVC去模拟页面访问控制呢？
我们以前的做法是通过前端页面（HTML或JSP的FORM属性指定请求方式和发送什么数据，更高级的话采用浏览器PostMan插件来模拟）
有了MockMVC以后我们就可以不用到前端页面和启动服务器的情况下来做测试了。
如何使用MockMVC
MockMvcBuilder是用来构造MockMvc的构造器，其主要有两个实现：StandaloneMockMvcBuilder和DefaultMockMvcBuilder，StandaloneMockMvcBuilder继承了DefaultMockMvcBuilder。
分别对应两种测试方式，即独立安装和集成Web环境测试（此种方式并不会集成真正的web环境，而是通过相应的Mock API进行模拟测试，无须启动服务器）。对于我们来说直接使用静态工厂MockMvcBuilders创建即可。
StandaloneMockMvcBuilder对应独立安装
DefaultMockMvcBuilder（默认的MockMVC工厂）对应WEB集成环境
关于这两种方式的应用场景嘛，我觉得普通测试的话两者并没区别，以后再总结。。。
集成Web环境方式
MockMvcBuilders.webAppContextSetup(new XXXController().build();：指定XXXController，将会从该上下文获取相应的控制器并得到相应的MockMvc；
通常我们是在Test案例中注入要测试的Controller来代入的
比如：
@RunWith(SpringJUnit4ClassRunner.class)
@WebAppConfiguration
public class HelloControllerTest(){
//注入要测试的HelloController
@Autowired
private HelloController helloController;
@Autowired
private UserController userController;
private MockMvc mvc;//创建MockMvc以便于在每个测试方法中调用
@Before
public void setUp() throws Exception{
//用webAppContextSetup创建这个Controller的Mock（模拟）,创建一个MockMvc进行测试
//如果有多个Controller也可以多次调用webAppContextSetup方法进行多次创建
mvc=MockMvcBuilders.webAppContextSetup(helloController,userController).build();
}
//测试案例
@Test
。。。
}
独立测试方式
MockMvcBuilders.standaloneSetup(Object… controllers)：通过参数指定一组控制器，这样就不需要从上下文获取了；
通过MockMvcBuilders.standaloneSetup模拟一个Mvc测试环境，通过build得到一个MockMvc
跟上面的集成方法代入参数一样，只是调用的方法不一致
MockMvc测试
看一个例子用于测试：
@Test
public void testView() throws Exception {
//MockMvc对象来实现
mvc.perform(MockMvcRequestBuilders.get("/user/1"))
.andExpect(MockMvcResultMatchers.view().name("user/view"))
.andExpect(MockMvcResultMatchers.model().attributeExists("user"))
.andDo(MockMvcResultHandlers.print())
.andReturn();
Assert.assertNotNull(result.getModelAndView().getModel().get("user"));
}
perform：执行一个RequestBuilder请求，会自动执行SpringMVC的流程并映射到相应的控制器执行处理；
andExpect：添加ResultMatcher验证规则，验证控制器执行完成后结果是否正确；
andDo：添加ResultHandler结果处理器，比如调试时打印结果到控制台；
andReturn：最后返回相应的MvcResult；然后进行自定义验证/进行下一步的异步处理；
@Test
public void testUserController() throws Exception {
// 测试UserController
mvc.perform(RequestBuilder.get("/users/"))
.andExpect(status().isOk())
.andExpect(content().string(equalTo("[]")));
}
RequestBuilder/MockMvcRequestBuilders都可以来模拟请求
从名字可以看出，RequestBuilder用来构建请求的，其提供了一个方法buildRequest(ServletContext servletContext)用于构建MockHttpServletRequest；其主要有两个子类MockHttpServletRequestBuilder和MockMultipartHttpServletRequestBuilder（如文件上传使用），即用来Mock客户端请求需要的所有数据。
MockMvcRequestBuilders主要API
MockHttpServletRequestBuilder get(String urlTemplate, Object… urlVariables)：根据uri模板和uri变量值得到一个GET请求方式的MockHttpServletRequestBuilder；如get(/user/{id}, 1L)；
MockHttpServletRequestBuilder post(String urlTemplate, Object… urlVariables)：同get类似，但是是POST方法；
MockHttpServletRequestBuilder put(String urlTemplate, Object… urlVariables)：同get类似，但是是PUT方法；
MockHttpServletRequestBuilder delete(String urlTemplate, Object… urlVariables) ：同get类似，但是是DELETE方法；
MockHttpServletRequestBuilder options(String urlTemplate, Object… urlVariables)：同get类似，但是是OPTIONS方法；
MockHttpServletRequestBuilder request(HttpMethod httpMethod, String urlTemplate, Object… urlVariables)： 提供自己的Http请求方法及uri模板和uri变量，如上API都是委托给这个API；
MockMultipartHttpServletRequestBuilder fileUpload(String urlTemplate, Object… urlVariables)：提供文件上传方式的请求，得到MockMultipartHttpServletRequestBuilder；
RequestBuilder asyncDispatch(final MvcResult mvcResult)：创建一个从启动异步处理的请求的MvcResult进行异步分派的RequestBuilder；
MockHttpServletRequestBuilder和MockMultipartHttpServletRequestBuilder API
(1)MockHttpServletRequestBuilder API
MockHttpServletRequestBuilder header(String name, Object… values)/MockHttpServletRequestBuilder headers(HttpHeaders httpHeaders)：添加头信息；
MockHttpServletRequestBuilder contentType(MediaType mediaType)：指定请求的contentType头信息；
MockHttpServletRequestBuilder accept(MediaType… mediaTypes)/MockHttpServletRequestBuilder accept(String… mediaTypes)：指定请求的Accept头信息；
MockHttpServletRequestBuilder content(byte[] content)/MockHttpServletRequestBuilder content(String content)：指定请求Body体内容；
MockHttpServletRequestBuilder cookie(Cookie… cookies)：指定请求的Cookie；
MockHttpServletRequestBuilder locale(Locale locale)：指定请求的Locale；
MockHttpServletRequestBuilder characterEncoding(String encoding)：指定请求字符编码；
MockHttpServletRequestBuilder requestAttr(String name, Object value) ：设置请求属性数据；
MockHttpServletRequestBuilder sessionAttr(String name, Object value)/MockHttpServletRequestBuilder sessionAttrs(Map<string, object=””> sessionAttributes)：设置请求session属性数据；
MockHttpServletRequestBuilder flashAttr(String name, Object value)/MockHttpServletRequestBuilder flashAttrs(Map<string, object=””> flashAttributes)：指定请求的flash信息，比如重定向后的属性信息；
MockHttpServletRequestBuilder session(MockHttpSession session) ：指定请求的Session；
MockHttpServletRequestBuilder principal(Principal principal) ：指定请求的Principal；
MockHttpServletRequestBuilder contextPath(String contextPath) ：指定请求的上下文路径，必须以“/”开头，且不能以“/”结尾；
MockHttpServletRequestBuilder pathInfo(String pathInfo) ：请求的路径信息，必须以“/”开头；
MockHttpServletRequestBuilder secure(boolean secure)：请求是否使用安全通道；
MockHttpServletRequestBuilder with(RequestPostProcessor postProcessor)：请求的后处理器，用于自定义一些请求处理的扩展点；
(2)MockMultipartHttpServletRequestBuilder继承自MockHttpServletRequestBuilder，又提供了如下API
MockMultipartHttpServletRequestBuilder file(String name, byte[] content)/MockMultipartHttpServletRequestBuilder file(MockMultipartFile file)：指定要上传的文件；
ResultActions
调用MockMvc.perform(RequestBuilder requestBuilder)后将得到ResultActions，通过ResultActions完成如下三件事：
ResultActions andExpect(ResultMatcher matcher) ：添加验证断言来判断执行请求后的结果是否是预期的；
ResultActions andDo(ResultHandler handler) ：添加结果处理器，用于对验证成功后执行的动作，如输出下请求/结果信息用于调试；
MvcResult andReturn() ：返回验证成功后的MvcResult；用于自定义验证/下一步的异步处理；
ResultMatcher/MockMvcResultMatchers
1.ResultMatcher用来匹配执行完请求后的结果验证，其就一个match(MvcResult result)断言方法，如果匹配失败将抛出相应的异常；spring mvc测试框架提供了很多ResultMatchers来满足测试需求。注意这些ResultMatchers并不是ResultMatcher的子类，而是返回ResultMatcher实例的。Spring mvc测试框架为了测试方便提供了MockMvcResultMatchers静态工厂方法方便操作；
2.具体的API如下：
HandlerResultMatchers handler()：请求的Handler验证器，比如验证处理器类型/方法名；此处的Handler其实就是处理请求的控制器；
RequestResultMatchers request()：得到RequestResultMatchers验证器；
ModelResultMatchers model()：得到模型验证器；
ViewResultMatchers view()：得到视图验证器；
FlashAttributeResultMatchers flash()：得到Flash属性验证；
StatusResultMatchers status()：得到响应状态验证器；
HeaderResultMatchers header()：得到响应Header验证器；
CookieResultMatchers cookie()：得到响应Cookie验证器；
ContentResultMatchers content()：得到响应内容验证器；
JsonPathResultMatchers jsonPath(String expression, Object … args)/ResultMatcher jsonPath(String expression, Matcher matcher)：得到Json表达式验证器；
XpathResultMatchers xpath(String expression, Object… args)/XpathResultMatchers xpath(String expression, Map<string, string=””> namespaces, Object… args)：得到Xpath表达式验证器；
ResultMatcher forwardedUrl(final String expectedUrl)：验证处理完请求后转发的url（绝对匹配）；
ResultMatcher forwardedUrlPattern(final String urlPattern)：验证处理完请求后转发的url（Ant风格模式匹配，@since spring4）；
ResultMatcher redirectedUrl(final String expectedUrl)：验证处理完请求后重定向的url（绝对匹配）；
ResultMatcher redirectedUrlPattern(final String expectedUrl)：验证处理完请求后重定向的url（Ant风格模式匹配，@since spring4）；
一些常用测试
测试普通控制器
mockMvc.perform(get("/user/{id}", 1)) //执行请求
.andExpect(model().attributeExists("user")) //验证存储模型数据
.andExpect(view().name("user/view")) //验证viewName
.andExpect(forwardedUrl("/WEB-INF/jsp/user/view.jsp"))//验证视图渲染时forward到的jsp
.andExpect(status().isOk())//验证状态码
.andDo(print()); //输出MvcResult到控制台
得到MvcResult自定义验证
MvcResult result = mockMvc.perform(get("/user/{id}", 1))//执行请求
.andReturn(); //返回MvcResult
Assert.assertNotNull(result.getModelAndView().getModel().get("user")); //自定义断言
验证请求参数绑定到模型数据及Flash属性
mockMvc.perform(post("/user").param("name", "zhang")) //执行传递参数的POST请求(也可以post("/user?name=zhang"))
.andExpect(handler().handlerType(UserController.class)) //验证执行的控制器类型
.andExpect(handler().methodName("create")) //验证执行的控制器方法名
.andExpect(model().hasNoErrors()) //验证页面没有错误
.andExpect(flash().attributeExists("success")) //验证存在flash属性
.andExpect(view().name("redirect:/user")); //验证视图
文件上传
byte[] bytes = new byte[] {1, 2};
mockMvc.perform(fileUpload("/user/{id}/icon", 1L).file("icon", bytes)) //执行文件上传
.andExpect(model().attribute("icon", bytes)) //验证属性相等性
.andExpect(view().name("success")); //验证视图
JSON请求/响应验证
String requestBody = "{\"id\":1, \"name\":\"zhang\"}";
mockMvc.perform(post("/user")
.contentType(MediaType.APPLICATION_JSON).content(requestBody)
.accept(MediaType.APPLICATION_JSON)) //执行请求
.andExpect(content().contentType(MediaType.APPLICATION_JSON)) //验证响应contentType
.andExpect(jsonPath("$.id").value(1)); //使用Json path验证JSON 请参考http://goessner.net/articles/JsonPath/
String errorBody = "{id:1, name:zhang}";
MvcResult result = mockMvc.perform(post("/user")
.contentType(MediaType.APPLICATION_JSON).content(errorBody)
.accept(MediaType.APPLICATION_JSON)) //执行请求
.andExpect(status().isBadRequest()) //400错误请求
.andReturn();
Assert.assertTrue(HttpMessageNotReadableException.class.isAssignableFrom(result.getResolvedException().getClass()));//错误的请求内容体
异步测试
//Callable
MvcResult result = mockMvc.perform(get("/user/async1?id=1&name=zhang")) //执行请求
.andExpect(request().asyncStarted())
.andExpect(request().asyncResult(CoreMatchers.instanceOf(User.class))) //默认会等10秒超时
.andReturn();
mockMvc.perform(asyncDispatch(result))
.andExpect(status().isOk())
.andExpect(content().contentType(MediaType.APPLICATION_JSON))
.andExpect(jsonPath("$.id").value(1));
全局配置
mockMvc = webAppContextSetup(wac)
.defaultRequest(get("/user/1").requestAttr("default", true)) //默认请求 如果其是Mergeable类型的，会自动合并的哦mockMvc.perform中的RequestBuilder
.alwaysDo(print()) //默认每次执行请求后都做的动作
.alwaysExpect(request().attribute("default", true)) //默认每次执行后进行验证的断言
.build();
mockMvc.perform(get("/user/1"))
.andExpect(model().attributeExists("user"));
整个测试过程非常有规律：
1、准备测试环境
2、通过MockMvc执行请求
3.1、添加验证断言
3.2、添加结果处理器
3.3、得到MvcResult进行自定义断言/进行下一步的异步请求
4、卸载测试环境
