Check out the sample code
Sample files: https://github.com/znsio/specmatic-redis-sample
Download Specmatic: https://github.com/znsio/specmatic/releases
Available in the Pro plan or higher
Transcript
Overview – how Specmatic can be used to stub out Redis
A typical HTTP consumer would send an HTTP request to an API where it is received by a controller. Let’s say the controller needs to fetch some data using a service object, and let’s say the service object looks up the data in an instance of Redis. Redis responds with the data, the service object returns it to the controller, and the controller uses the data to formulate a response to the consumer. This is how it works in production. But in test mode, things might be a little different. Let’s say there’s an OpenAPI specification for the API, and we feed it to Specmatic to run contract tests against the API. Instead of using an actual instance of Redis, we’ll stub it out and have the contract test set expectations so that the Redis stub knows what data to return for any query sent to it by the application. Now, when we run the contract tests and the service object does a look up in Redis, it’s actually hitting the Redis stub. The Redis stub responds and the service class understands it. None the wiser that it isn’t an actual instance of Redis.
The stub is wire compatible, so no changes are needed in the service class for this to work.
Specmatic Redis stub in action
Let’s take a sample API that needs Redis to function. Here’s the StoreController class using the StoreService object to look up some data.
The StoreService object, in turn, looks up Redis. We’re now going to run contract tests against this API using its API specification. The contract tests will be generated from the specification by Specmatic. The specification from which the contract tests are generated is in a central Git repository.
You can learn more about how Specmatic runs contract tests in a previous video.
Now, let’s run the contract tests. It won’t take long. Let’s take a look at the first test. Let’s scroll down a little in the logs. We can see a test here for a GET API to fetch the description of a store with ID 1. We get this response.
This description was provided by a Redis lookup. If we scroll up a little, we can see the log from the Redis tab showing the request that it received and the response that it returned. The stub itself is wire compatible. So the same code that talks to an actual Redis instance will talk to Specmatic’s Redis stub. But how did the stub know to return this response? Let’s dig a little deeper. Just after starting up the stubbed Redis instance, we set expectations on it.
For example, when it receives a GET operation with description hyphen 1, it should return this response, and so on. In fact, we can do dependency fault injection here. The Redis stub can simulate Redis errors to test that our application responds appropriately. The Redis stub setup is self contained within the test. The stub itself starts up within a millisecond. And this is all great because this test can easily run now in CI or even just locally on the laptop.