Both forms are actually integration tests since you are testing the integration of your code with the Spring DispatcherServlet
and supporting infrastructure. The difference lies in the amount of supporting infrastructure that is used behind the scenes.
The details are documented in the Spring reference manual.
Noteworthy excerpts:
The "webAppContextSetup" loads the actual Spring MVC configuration
resulting in a more complete integration test. Since the TestContext
framework caches the loaded Spring configuration, it helps to keep
tests running fast even as more tests get added. Furthermore, you can
inject mock services into controllers through Spring configuration, in
order to remain focused on testing the web layer.
...
The "standaloneSetup" on the other hand is a little closer to a unit
test. It tests one controller at a time, the controller can be
injected with mock dependencies manually, and it doesn’t involve
loading Spring configuration. Such tests are more focused in style and
make it easier to see which controller is being tested, whether any
specific Spring MVC configuration is required to work, and so on. The
"standaloneSetup" is also a very convenient way to write ad-hoc tests
to verify some behavior or to debug an issue.
...
Just like with integration vs unit testing, there is no right or wrong
answer. Using the "standaloneSetup" does imply the need for some
additional "webAppContextSetup" tests to verify the Spring MVC
configuration. Alternatively, you can decide to write all tests with
"webAppContextSetup" and always test against actual Spring MVC
configuration.
...
The options provided in Spring MVC Test are different stops on the
scale from classic unit to full integration tests. To be sure none of
the options in Spring MVC Test are classic unit tests but they are a
little closer to it. For example you can isolate the service layer
with mocks injected into controllers and then you’re testing the web
layer only through the DispatcherServlet and with actual Spring
configuration, just like you might test the database layer in
isolation of the layers above. Or you could be using the standalone
setup focusing on one controller at a time and manually providing the
configuration required to make it work.
When in doubt, I suggest first reading the reference manual before posting questions here. ;)
Regards,
Sam (author of the Spring TestContext Framework)