Using mocks in the presentation tier.

[nc_heo]

Hi,

I have a question which is only somewhat related to the Spring Framework, but I hope to get your opinion anyway.

Let's say that I'm developing a web application. The application is divided into the three typical tiers (presentation, service and data). When the developers are working on the service tier and the data tier they are producing unit tests (with other classes mocked out) and integration tests (with only foreign systems mocked out). They are able to run both kinds of tests in their IDE (i.e. outside the container) - the latter thanks to the Spring integration test package.

When the developers need to do some work on the presentation tier (based on some MVC framework), they are not fully able to do this in the IDE. The controllers can be efficiently unit tested in the IDE, but the JSPs need to be deployed to the container. The deployed war file contains the "real-environment" configuration of the controllers , meaning that they will contact the service layer, which is not what the developers want as they are only concerned with the frontend code. What usually happens is that the developer hardcodes the return values of the controllers to fit the functionality he is currently developing. When he is done he commits his changes to source control. The changes to the controllers are of course not committed since these would affect the system in a real environment.

The next time a change to a JSP is required, the developer needs to redo the hardcoding in the controllers. This is a terrible waste of time. What do you do to avoid it?

One solution (which I haven't tried) is to have one war-file for local development and one for the real environments. The only difference between the two war-files would be configuration of the controllers. The local configuration would be added to source control such that it is available for all developers.
I am not entirely fond of that solution because of the risk of having an outdated local configuration file.

Best regards,

Henrik

[MartyJones]

I have two service beans defined in my configuration file (One is commented out). When I am developing, I comment out the JDBC service bean reference and uncomment my Mock service bean so I can unit test and test the web application. When deploying to a production environment, I comment out the mock bean reference and then uncomment out the JDBC bean reference.

Hope this helps.

[Marten Deinum]

A Unit test should be stripped from the outside world (even Spring) as much as possible. So you would just create a new instance of your controller, Mock or Stub the dependencies and then run the test. (You don't mess around with modifying your xml files).

If you want to do a integration test then instead of your production jdbc you use a stripped down version of it, preferably the same database but if needed an in memory database (just include a different datasource from a different infrastructure xml file). You can do the same for web testing, simply use an embedded instance of Jetty, tell it where to look for files and you can run an integration test for your web application, just include a dummy datasource and you can test everything. The developers don't even have to click the links anymore, they would have to write the testcase (just once).

That way you don't have to mess around each time, saves you a lot of time and you could even use Continues integration to test everything. If you have to change files each time this would be impossible.

[nc_heo]

A Unit test should be stripped from the outside world (even Spring) as much as possible. So you would just create a new instance of your controller, Mock or Stub the dependencies and then run the test. (You don't mess around with modifying your xml files).

If you want to do a integration test then instead of your production jdbc you use a stripped down version of it, preferably the same database but if needed an in memory database (just include a different datasource from a different infrastructure xml file). You can do the same for web testing, simply use an embedded instance of Jetty, tell it where to look for files and you can run an integration test for your web application, just include a dummy datasource and you can test everything. The developers don't even have to click the links anymore, they would have to write the testcase (just once).

That way you don't have to mess around each time, saves you a lot of time and you could even use Continues integration to test everything. If you have to change files each time this would be impossible.

The solution with an embedded instance of Jetty sounds very promising. Exactly what I'm looking for. Looking very much forward to trying it out.

Thanks.

Henrik