Using mocking to keep development agile

We had built up a mocked service layer for our Wicket Tester unit tests (with Mockito). This enables our unit test to start any page or panel in our app with reasonable test data. However, when it came to development, we were still using the real service layer – which meant that as our application got bigger it took longer and longer to start and navigate to the page under development.

Why not use the mocked services during development too? Good idea, we thought. We added development entry points to our unit tests which allow us to start a minimal Jetty container to run the pages under development in a mocked service sandbox.

Turns out this works great – start time goes down from 10 seconds to 1 second and you have all the power of the mock scenarios already developed for unit tests during development.

This not only saves time during development, but encourages better unit tests (since you build better mock scenarios during development and can then reuse them for unit tests).

It also finally allows us to decouple application development from service development, meaning that the application developers can start immediately with application development and contribute to the definition of the service layers from a client perspective by creating mocks as needed.

Using Maven for production deployment

We use Maven to manage dependencies during development. This entails adding a pom.xml file to our Eclipse project which defines the jars which the application depends. Maven then takes care of fetching the right version of the jars from a number of repositories (central maven repository, vendor specific repositories, our own repository).

This works pretty well and its hard to imagine developing complex projects without this capability. However, when it comes to ensuring that an application is delivered to the production environment with all its dependencies, you’re pretty much on your own. You have to build either a war file or a jar-with-dependencies – both of which can be very tricky and lead to problems occurring in production which you never saw during development.

Additionally, our applications tend to have a lot of dependencies and the war files get huge.

So, we thought, why not just use Maven on production servers to fetch applications and their dependencies.

To do this we maintain a pom.xml file on the production server with the application listed as a dependency. We use the maven goals “versions:use-latest-releases” and “versions:commit” to update the pom file automatically to the latest release version. We then use the “dependency:build-classpath” goal to build a class path from the repository and finally run the application.