How to setup code for Maddox

Let's take a look at an example. In this example we are the owners of a service called the PersonBuilderService and it is our goal to test it. The PersonBuilderService is in charge of building building a persons name from their first, middle, and last names, and then saving this full name to a database.

This environment is graphed below. Each color coded box, is a set of services owned by a different team. Our team owns the blue service. This service is in charge of getting the first name from the FirstNameService, the middleName from the MiddleNameService, and the last name from the LastNameService. Then it combines these results and asks the SavePersonService to save its results.

880

You will see that we have four proxies in our service. Ideally these proxies are all in a single directory. The proxies are code that encapsulate the communication to each individual service. This is considered a "best practice" when testing with Maddox. Not only will this practice allow you to control the the inputs and outputs of an external service in a single place, but it also gives you an encapsulated layer to mock when running your Maddox tests. Just to reiterate, these four proxies represent four different files of code in our PersonBuilderService.

In the real world, you probably wouldn't need a different proxy layer for each service. You may be able to have a single proxy that handles all HTTP calls. You should evaluate your situation and answer this question yourself. We will keep four different proxies in our example to keep the explanation more explicit.

Before we dig into some code, I will mention again, that you can find an examples of all scenarios in the test suite of Maddox. Maddox takes the philosophy of using itself to test itself which leads to great documentation via test.