Introduction

At my current client there was a request to create a sandbox version of our RESTful web services to allow users to call into the web services and test them out without changing with any data. We use the standard DAO and service layers along with Spring, Spring JDBC, Spring Security, Bean Validation, etc. In this case we wanted to mock the DAO layer so that we still went through all the other layers and still got everything the other layers had (with the exception of Spring Security since it didn’t apply in our case). Below are the steps that were taken to achieve this.

Mocked DAO Project

The first step was a mocked DAO project which implements the DAO interfaces with mocked implementations. These DAO’s are Spring injected so a change will need to be made to the Spring config in the RESTful web service project to use the mocked DAO’s, more on that below. First is an example POM file which pulls in the DAO project as a dependency along with the Groovy dependencies.

Now to the fun part of creating mocked objects using Groovy. Here’s an example of a mocked user DAO that just returns a User with a random first name and last name and a couple other fields. There’s a number of different ways to create mock data, and Groovy makes it very easy with the map constructor and metadata extensions.

Note the random examples above, this is made possible with the following metadata extension. Groovy also adds a toList() method to array so UserType can get the values, call toList() and then random.

The Sandbox Server Project

Below is the pom for the sandbox server, one of the things it does is unpack the original rest server war file into the target of the sandbox server so that the original structure is maintained and whatever files are in the mocked-dao project will overwrite those that have been unpacked. Because of this any changes that are made to the original project will be included. This is referred to as an overlay. As part of this, the original applicationContext.xml file from the restful-server project will be replaced with the mocked one from this project.

Below is the mocked applicationContext file, the key here is to put it in the same location is the original rest server, so if the original one is in src/main/webapp, put this one in the same place so it gets overridden.

There’s two options for how to set up the above spring config file, the first is to component scan the services and the DAO’s. This didn’t work in our case because there were several services that were not being used that we didn’t want to have to write extra mock DAO’s for, so we just listed them individually. Obviously there is some maintenance when there are changes to DAO’s, but unless there is a major refactor, it’s not usually too bad to deal with.

Conclusion

This type of sandbox server is very handy for those who wish to test out web services (or any type of service) without harming the data. It allows them to test out validation, and everything else but no data is changed and the performance is very good as well.