tag:blogger.com,1999:blog-3237724005744642470.post3898488096872660730..comments2020-05-08T12:31:27.297+01:00Roger Hugheshttp://www.blogger.com/profile/07042290171112551665[email protected]Blogger2125tag:blogger.com,1999:blog-3237724005744642470.post-88226217238703551422013-07-19T17:41:49.783+01:002013-07-19T17:41:49.783+01:00Spiff,<br />Thanks for the comment. <br /><br />I think that using Spring MVC Test framework for server-side integration tests is the right approach. The reason being that, as you say, they’re quicker than Selenium based tests and therefore you’d tend to run them more often (eg: before checking in or as part of the main build server’s build). That said, if you have Selenium tests, then there’s no point in throwing them away, they will verify that your front end code is working, just run them less often; may be to verify a release.Roger Hugheshttps://www.blogger.com/profile/07042290171112551665[email protected]tag:blogger.com,1999:blog-3237724005744642470.post-26183160388366511752013-07-17T15:21:37.990+01:002013-07-17T15:21:37.990+01:00Very useful and well-written, as always.<br /><br />I&#39;ve been looking at Spring MVC Test and thinking about where it fits in a global test strategy. For the last few weeks I&#39;ve been doing Selenium-based tests and while I appreciate the end-to-end validation it brings, it takes way too much time to get feedback. I was going to move to integration tests that invoke the service layer, but now am thinking that maybe I would get broader feedback writing integration tests that invoke the web controller through Spring MVC Test. Of course a set of unit tests would still support all of this. <br /><br />What do you think?Spiffhttps://www.blogger.com/profile/10155008993215382923[email protected]