Jun 25, 2015

Creating a Mocked RESTful Sandbox Server using Groovy


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.


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.

About the Author

Object Partners profile.

One thought on “Creating a Mocked RESTful Sandbox Server using Groovy

  1. Ben says:

    Another way to solve this problem is to re-create your endpoint mappings using Node.js and then just return mocked up JSON data from in there.

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Blog Posts
Feature Flags in Terraform
Feature flagging any code can be useful to developers but many don’t know how to or even that you can do it in Terraform. Some benefits of Feature Flagging your code You can enable different […]
Infrastructure as Code – The Wrong Way
You are probably familiar with the term “infrastructure as code”. It’s a great concept, and it’s gaining steam in the industry. Unfortunately, just as we had a lot to learn about how to write clean […]
Snowflake CI/CD using Jenkins and Schemachange
CI/CD and Management of Data Warehouses can be a serious challenge. In this blog you will learn how to setup CI/CD for Snowflake using Schemachange, Github, and Jenkins. For access to the code check out […]
How to get your pull requests approved more quickly
TL;DR The fewer reviews necessary, the quicker your PR gets approved. Code reviews serve an essential function on any software codebase. Done right, they help ensure correctness, reliability, and maintainability of code. On many teams, […]