 In this video, we'll show 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. This 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 open API 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 doesn't 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. Let's see how this works in an example. Here's a sample API that needs Redis to function. Here's the store controller class using the store service object to look up some data. The store service 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 a specmatic. The specification from which the contract tests are generated is in a central grid repository at this path. 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, the tests are starting up, there you go. 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 stub, 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 specmatics Redis stub. But how did the stub know to return this response? Let's dig a little deeper. Just after starting up the stub Redis instance, we set expectations on it. For example, when it receives a get operation with description-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.