Testability is one of the key principles behind the Spring framework (i.e., the ability to test each component in the framework regardless of its nature). In this sense, Spring was a major improvement over the core J2EE model, in which the components were hard to test outside of the container. Even in-container testing required significant and often complicated setup. (See Sidebar: Why Testability Is Important.)
This article describes Spring's testability features, specifically the practical features that make unit testing Web components as easy as testing plain old Java objects (POJOs).
Introducing Spring Mock Classes
Mock object is a term originally popularized by the eXtreme Programmers and the JUnit team. In the context of unit testing, a mock object is an object that implements some well-known object interface with a "dummy" placeholder functionality. These dummy placeholder objects simulate in a very simplistic fashion the expected behavior and results of a component under test, allowing you to focus solely on the thorough testing of the component itself without worrying about other dependencies.Spring provides a mock implementation for each key interface from the Web side of the J2EE spec:
- MockHttpServletRequest You most likely will find a use for this class in every single one of your unit tests. It is the mock implementation of the most frequently used interface in J2EE Web applications: HttpServletRequest.
- MockHttpServletResponse Use this object for mock implementations of the HttpServletResponse interface.
- MockHttpSession This is another frequently used mock object. (This article will review use of this class for session-bound processing later.)
- DelegatingServletInputStream Use this object for mock implementation of the ServletInputStream interface.
- DelegatingServletOutputStream This object delegates the implementation of ServletOutputStream. It can be useful if you need to intercept and examine the content written to an output stream.
As already stated, you most likely will find the most use for mock HttpServletRequest, HttpServletResponse, and HttpSession while testing your controllers. However, Spring also provides the following mock implementations to other less frequently used components that you may find useful on their own, especially if you are an API developer:
- MockExpressionEvaluator You use this mock object mostly when you intend to develop and test your own JSTL-based tag libraries.
- MockFilterConfig This is a mock implementation of the FilterConfig interface.
- MockPageContext This is a mock implementation of the JSP PageContext interface. You may find this object useful for testing pre-compiled JSPs.
- MockRequestDispatcher This is a mock implementation of the RequestDispatcher interface. You use it mostly within other mock objects.
- MockServletConfig This is a mock implementation of the ServletConfig interface. Unit testing some Web components, such as the ones the Struts framework supplies, requires you to set the ServletConfig and ServletContext interfaces implemented by MockServletContext.
So, what does it take to use these mock objects? As you know, HttpServletRequest is a component that holds immutable values that represent HTTP parameters. These parameters are what drive the functionality of the Web components. MockHttpServletRequest, which is an implementation of the HttpServletRequest interface, allows you to set these otherwise immutable parameters. In a typical Web component-testing scenario, you can instantiate this object and set any of the parameters as follows:
<code> //specify the form method and the form action MockHttpServletRequest request = new MockHttpServletRequest("GET", ""); request.addParameter("choice", expanded); request.addParameter("contextMenu", "left"); </code>
Similarly, you can instantiate, fully manipulate, and examine the HttpResponse and HttpSession objects.
Now let's see how you can make JUnit tests Spring-aware.