While this test is checking that the correct account was activated, it is also subtly checking
that the parameter passed to activateAccount() is correctly passed to the getAccount()method
of the DAO. When we instruct the mock object to expect a call “with a parameter equal to new
Long(1)”, we are telling the mock to throw an exception if it receives a different value. Therefore,
we are also testing that we are calling the DAO with the correct information.
If the wrong or unexpected value is passed to the mock (for this example, the value of 2),
the mock will throw an exception looking much like the following the one in Listing 10-8.Listing 10-8.Incorrect Value Passed to Mockorg.jmock.core.DynamicMockError: mockAccountDao: no match found
Invoked: com.apress.expertspringmvc.testing.AccountDao.getAccount(<2>)
Allowed:
expected once: getAccount( eq(<1>) ), returns
<com.apress.expertspringmvc.testing.Account@1a05308>at org.jmock.core.AbstractDynamicMock.mockInvocation(Unknown Source)
at org.jmock.core.CoreMock.invoke(Unknown Source)
at $Proxy0.getAccount(Unknown Source)
at com.apress.expertspringmvc.testing.AccountServiceImpl.activateAccount(
AccountServiceImpl.java:15)Mock Objects Summary
Mock objects are an excellent way to write unit tests for components that rely on dependen-
cies that would otherwise be heavyweight or difficult to test. Mocks are intelligent stubs, able
to be scripted to expect certain inputs and respond with certain outputs. You should use
mocks when the dependency would violate some of the unit test guidelines, most importantly
“run fast” and “zero external resources.”
Mocks can be scripted to expect one or more methods, called in a particular order, and
with a particular set of parameters. Mocks can return any preset value, throw an exception
instead of returning a value, or simply return void.
Mocks will fail a test if the code under test uses the mock in unexpected way, or doesn’t
exercise the mock at all. If using jMock, remember to call verify()on your mock objects at
the end of the test case to ensure all expectations are met.
Mocks don’t have to be used for replacements of heavyweight objects such as DAOs. They
can be used anywhere dependencies are found, making it easy to isolate the class under test
by ensuring that all other participants in the test perform and behave exactly as specified.Testing Controllers
Up to this point, we’ve discussed testing both the domain object model as simple JUnit
tests and testing the service layer with the help of mock objects. The web layer has its own
set of testing tips and tricks, as it requires both the service layer and Servlet API classes.
Testing Controllers requires both mock objects and a set of stubs for classes such as
HttpServletRequestand HttpSession. Tests for Controllers can be written just as easily
as service layer tests and can be run just as fast.296 CHAPTER 10 ■TESTING SPRING MVC APPLICATIONS