I should be using Maddox because...

Maddox is is a BDD scenario testing framework with performance testing built in. Why write separate performance tests when you can just use your scenario tests?

Automating tests around the actions to and from external dependencies is a difficult task, but still very important. After working in a microservices environment for sometime now, we have recognized that most services ignore these scenarios all together. After all, we can't take down a dependent service just to test if we handle failure scenarios from that service correctly. Granted, it isn't always necessary to go to such extremes to test the actions to and from our dependencies. Sometimes it is possible to test these scenarios using integration tests, but do we really want to leave these use cases for just integration tests? Wouldn't it be nice to have the benefits of unit testing when validating these behaviors?

Welcome to Maddox. Maddox provides a simple way to rapidly unit test complex success and failure scenarios which can be driven by responses of other mocked external calls. This allows you automate testing around complex scenarios that have been missing from your test suites. It also allows you to mark any of your tests are runnable performance tests.

Below are common use cases that are particularly difficult to design and automate in your test suites. For the purpose of these uses cases, let's assume the following:

We have a service that we are testing called ServiceToTest.
ServiceToTest makes one individual calls to two other services.
First it makes a call to Service A.
Then it makes a call to Service B.

Given this setup, consider how Maddox allows us to test the following scenarios with ease.

Use Cases

You want to use your unit test suites for performance testing.
In ServiceToTest, we want to use the results from Service A to pass into Service B. i.e. the output of one service dictates the input into another service.
We want to prove that, when Service A returns "X", then ServiceToTest should NOT call Service B. But if Service A returns "Y", then ServiceToTest should call Service B. i.e. The outcome of one service dictates when another service gets executed.
In ServiceToTest we want to prove that, when Service A fails, we do NOT call Service B and we propagate the correct error message to the entry point of our test.
In ServiceToTest we want to prove that, when Service B fails, we did call Service A first, and we propagate the correct error message to the entry point of our test that came from Service B.
In ServiceToTest we want to prove that, when Service A fails, we still called Service B. i.e. One dependency failure doesn't stop the request.
In ServiceToTest if Service A fails with a certain error code, we would like to retry the execution of Service A before officially failing. i.e. Testing retry logic to make sure code is actually executed after a failure.

As you will see, Maddox easily allows you to test all of your functional business requirements, from end to end, without hitting your external dependencies. Not only is this a perfect framework for testing the difficult use cases already mentioned, but it also simplifies any test scenarios that necessitate mocking. This includes any external dependencies (of any kind) that may need to be mocked, but also when you have the need to mock a layer of your code.