Dodging Dependency Nightmares with a Serialization Module

In Serializing POJOs with Jackson we looked at creating simple classes just for serialization. In this article, we pull those classes into their own module, DRY and ready to be reused. This is a little more work up front, but it’s more of an investment than a cost.

Starting Point

This is a popular starting module structure on my projects:

+ locomotives
|
|--- webservice
|--- acceptance-tests
starting point

Our new wrinkle from the previous post is we now have some classes that our web services want to return and our acceptance-tests want to create.

Options

Many folks immediately see only two options:

  • duplicate all of the serialization classes
  • introduce a dependency between acceptance-tests and webservice modules

It’s easy to have a knee-jerk reaction to violating the DRY principal by duplicating classes and instead add the rest of the application as a dependency.

the wrong way to share code

This must be avoided. Acceptance tests should be black-box tests, knowing nothing of the implementation. Allowing the acceptance tests to access the rest of the codebase easily spirals into a tangled mess. Suddenly our tests can taken any view of the world they like - including accessing datastores directly and skipping validations. The door is now wide open for testing low-value states of the system that aren’t even possible for users to create. Even worse, the tests can become so coupled to internal code that it becomes difficult to refactor and improve the application. All of these consequences work against the original intent of our tests - to be a safety net.

Solution

Adding a new module is the best option. We’re going to take our nice, new, dependency-free serialization classes and move them into their own module. The dropwizard folks recommend calling this api, and I think that’s a great idea.

+ locomotives
|
|--- webservice
|--- api
|--- acceptance-tests

Now we have a third module and our dependency tree looks much better.

a new module

Putting this kind of thought into a growing application is an important part of continuing to evolve a codebase efficiently, leaving little chance of introducing unwanted coupling to accidental dependencies.

How Do I Make Cross-Platform File Paths in Java?

It’s a lot easier to deploy your Java application cross-platform if you consider a few small details like file paths first.

Read More

Google Play Android App Screenshots

Excited about releasing my first app to Google Play, I captured some thoughts from looking at other app screenshots in the store.

Read More

Guest Lecture

After practicing TDD in industry for a few years, I was invited to be a guest lecturer with a coworker at a nearby university. After an intriguing and dismissive comment from the crowd, we had a great discussion about the benefits of TDD.

Read More

Subtle Time Zone Bugs

Timezone bugs creep up from time to time. Understanding where timezone bugs will occur is key to preventing them. To get a quick idea of if you have timezone issues, consider running your automated tests in another timezone.

Read More

sghill’s Golden Rule

After going over well on a project, I tried coin my very own rule. We’ll see how we’ll it’s doing in another few decades.

Read More

002: Testing the Limits of Fun

A string-heavy design leads to trouble in the test data when later trying to move to a type-safe design. The story of how my test data invented a month and cost a pair some investigation time later on.

Read More

  • 1