Testing Dropwizard UI Apps in Memory

February 13, 2017

If you’re in javaland, you can do a lot worse than Dropwizard.

A simple, lightweight web service framework built on top of Jersey with an all-star cast of mature java libraries in supporting roles.

In-process testing is the essential technique for fast feedback when writing software. It involves having a test process (e.g. Junit) start your application and hosting it in-memory, firing requests at the app directly from an in-memory test client.

No packaging of the application. No deployment. No network IO for requests. Direct access to the application to mock external dependencies. Mock behaviour defined in code, sitting with your tests.

You can have a comprehensive, large-scale test suite run in seconds, which when multiplying that by the team size and number of pushes a day, is a backbone of time-saving techniques that power high-performing teams.

Dropwizard already has out-of-the-box support for in-process testing, but:

Here’s a tutorial for how to set up a DI-switchable integration test harness with Dropwizard and Guice, and as an added bonus, how to set that up for UI apps so you can use webdriver in-memory too.


	compile "com.hubspot.dropwizard:dropwizard-guice:",
    testCompile "junit:junit-dep:4.11",
  1. In your test code, override your guice bindings in the areas that you want to mock (e.g. time, external dependencies). Use your production guice module as the base (e.g. AppModule)
    Injector injector = Guice.createInjector(Stage.PRODUCTION, Modules.override(new AppModule()).with(binder -> {
  1. Expose a list of resources in your DW appication class, and use ResourceTestRule instead of DropwizardAppRule. Add resource classes from the injector (my app is called App here)
    ResourceTestRule.Builder builder = new ResourceTestRule.Builder();
    for (Class resource : new App().getResources()) {
    JerseyGuiceUtils.reset(); //Because of https://github.com/HubSpot/dropwizard-guice/issues/95
    ResourceTestRule rule = builder.build();
  1. Use a Junit ClassRule in your test class (or superclass) to point to your built rule (i happened to wrap that up in a harness)
    public static final ResourceTestRule rule = HARNESS.getRule();

Enter jerseytester

This library provides a webdriver interface on top of a Jersey client, adapting requests and responses so you get all the good stuff from HTMLUnitDriver - persistent browser state, cookies, and the page being traversable by that sweet API.

  1. ResourceTestRule exposes a client, use this to bootstrap the webdriver
    driver = new JerseyClientHtmlunitDriver(rule.client());
  1. Profit!

    Here is an example of using mockito at runtime to manipulate the response of the mock. (Baseuri for ResourceTestRule is “http://localhost:9998”)

	public void theHomepageIsVisited() {
	public String homepageText() {
	    return driver.findElement(By.tagName("body")).getText();
	public void theHomePageResponseIs(String message) {

For context, the production code that uses the ResponseProvider is:

	public class HelloWorldResource {

	    private ResponseProvider responseProvider;

	    public HelloWorldResource(ResponseProvider responseProvider) {
	        this.responseProvider = responseProvider;

	    public Response getHelloWorld(){
	        return Response.ok(responseProvider.get()).build();

	private void validateInProcessMocking(String message) {
	    assertThat(then.homepageText(), is(message));

Next time….

I’ll post about how to get webdriver working with your javascript