Testing Dropwizard

Testing Representations

While Jackson’s JSON support is powerful and fairly easy-to-use, you shouldn’t just rely on
eyeballing your representation classes to ensure you’re actually producing the API you think you
are. By using the helper methods in JsonHelpers you can add unit tests for serializing and
deserializing your representation classes to and from JSON.

Let’s assume we have a Person class which your API uses as both a request entity (e.g., when
writing via a PUT request) and a response entity (e.g., when reading via a GET request):

Fixtures

First, write out the exact JSON representation of a Person in the
src/test/resources/fixtures directory of your Dropwizard project as person.json:

{"name":"Luther Blissett","email":"lb@example.com"}

Testing Serialization

Next, write a test for serializing a Person instance to JSON:

importstaticcom.yammer.dropwizard.testing.JsonHelpers.*;importstaticorg.hamcrest.Matchers.*;@TestpublicvoidserializesToJSON()throwsException{finalPersonperson=newPerson("Luther Blissett","lb@example.com");assertThat("a Person can be serialized to JSON",asJson(person),is(equalTo(jsonFixture("fixtures/person.json"))));}

This test uses Hamcrest matchers and JUnit to test that when a Person instance is serialized
via Jackson it matches the JSON in the fixture file. (The comparison is done via a normalized JSON
string representation, so whitespace doesn’t affect the results.)

Testing Deserialization

Next, write a test for deserializing a Person instance from JSON:

importstaticcom.yammer.dropwizard.testing.JsonHelpers.*;importstaticorg.hamcrest.Matchers.*;@TestpublicvoiddeserializesFromJSON()throwsException{finalPersonperson=newPerson("Luther Blissett","lb@example.com");assertThat("a Person can be deserialized from JSON",fromJson(jsonFixture("fixtures/person.json"),Person.class),is(person));}

This test uses Hamcrest matchers and JUnit to test that when a Person instance is
deserialized via Jackson from the specified JSON fixture it matches the given object.

Testing Resources

While many resource classes can be tested just by calling the methods on the class in a test, some
resources lend themselves to a more full-stack approach. For these, use ResourceTest, which
loads a given resource instance in an in-memory Jersey server:

In your #setUpResources() method, instantiate the various resource instances you want to test
and add them to the test context via #addResource(Object). In your actual test methods, use
#client() which returns a Jersey Client instance which will talk to your resource instances.

This doesn’t require opening a port, but ResourceTest tests will perform all the serialization,
deserialization, and validation that happens inside of the HTTP process.

This also doesn’t require a full integration test. In the above
example, a mocked PersonDAO is passed to the
PersonResource instance to isolate it from the database. Not only does this make the test much
faster, but it allows your resource unit tests to test error conditions and edge cases much more
easily.

Hint

You can trust PersonDAO works because you’ve got working unit tests for it, right?

Should you, at some point, grow tired of the near-infinite amount of debug logging produced by
ResourceTest you can use the java.util.logging API to silence the com.sun.jersey logger.