 Hi! In this video, we'll see how to run contract tests against a service which talks to Google Pub server instance. Let's say we have an order service which talks to a Google Pub server instance. Order service listens to the messages on the place order topic. And for every message it receives, it sends one message on the process order topic and one message on the notification topic. So typically, a client of this service would send a message on the place order topic and receive messages on the process order and notification topics. To run the contract test against this service, we use the Google Pub server emulator instead of the actual Pub server instance. This helps in running the test fast without having to depend on the actual Pub server instance. Specmatic can then leverage the order services async API specification to run the contract test. In the contract test, Specmatic will act like a client of the order service and send a message on the place order topic. Specmatic will then wait for the messages on the process order and notification topics. It will validate two things. First, exactly one message is received each on the process order and notification topics. Second, received messages added to the schema defined in the async API specification. If either of these two conditions are not met, Specmatic will fail the contract test. With this background, let's see a code demo. Let's first have a look at the async API specification that the order service is based on. The specification is stored in a file called order service.yaml. Let me just copy this specification and put it here in the async API studio so that we have a good view on this. We can see in this particular specification, we have three topics place order, process order and notification. Place order is a published topic and the other two are the subscribe topics. All right. Now let's go back to the code and let's have a look at the contract test that we have written using Specmatic. Let's just directly run this test. All right. The test has passed. Okay. Let's now have a look at how this test is written. So we cannot see any tests written over here. Then how is this test getting generated and how it is getting executed over here? This all is done by Specmatic automatically and to generate the test, Specmatic refers to the async API specification that we have over here. Okay. But how does the Specmatic know what async API specification to refer to? For that, we have a file called specmatic.json. And if you look at this file, you'll see under the test key, we have specified the file order service dot yaml. And this file contains our async API specification. With the help of this file, which is specmatic.json, specmatic is able to figure out what async API specification to refer to in order to generate this test. Now let's just have a quick look at what all things are there in this particular test class. Okay, so we have a project ID and we have the topic names. Apart from that, we have an application context. We also have the PubSub emulator that we talked about in the slides. We are instantiating this emulator by passing the project ID to it and a list of topics that it should create. In the setup method, we are starting the PubSub emulator. Then we are connecting to the specmatics Google PubSub mark by passing project ID to it. And finally, we are starting the order service. Once this setup function is run, specmatic will generate the test and execute them. After that, in the teardown method, we are stopping the application. Then we are stopping the specmatics Google PubSub mark, which will return us a result pack. This result indicates that all the expectations set while running the contact us are met or not. If the expectations are met, the test will pass, otherwise the test will fail. And finally, we are stopping the PubSub emulator. Now let's look at the logs of the test that has run. Remember one thing, specmatic acts as a client of the order service as part of this contact us, as we have also discussed in the slides before. Okay, what does the logs say? The log says, specmatic has published a message with ID 1 on topic please order. And this is the message that it has published. Apart from that, specmatic is also awaiting a message on topic press order, as well as it is awaiting a message on topic notification. Specmatic has also received a message on those respective topics. Since these messages added to the schema that is defined in the eSync API specification, the test has passed. Okay, that's fine. But how did specmatic figure out what message to send and what message to expect back from the other two topics? Again, for this, specmatic leverages the eSync API specification. If we go and have a look at the place order in the specification, we can see it has got an example. And if we have a look at this example, this is the exact message that specmatic is publishing on this topic during the contact us. Apart from that, if we have a look at the examples of the other two topics, this is having total amount 3000 and status process for process order. If we go and have a look at the process order topic is the same data. And there will be an example for the notification topic as well. If I look for notification, yeah, it's the same example. So specmatic makes use of these named examples in order to figure out what message to publish on a published topic and what message to expect on a subscribe topic. Another key thing to note here is that all the examples have the same name, which is new order. We look at it. Press order also has the example named new order and notification also has the example named new order. Specmatic uses this common name to tie up these examples and use them in a contact us. So specmatic will send a message on the place order topic using its named example and wait for the messages on the process order and notification topics based on their corresponding named examples. Alright, this is all green. But how does this help me in not deviating from the spec? To figure that out, let's try out one thing. Let me go to order service. And what I'll do is I'll update the key name in the message that we are sending to the process order topic from total amount to total amounts so that we are not adhering to the async ABS specification that we have specified over here. And now let's run the contact us. Since we are not adhering to the async ABS specification, we expect this test to fail. Alright, the test has failed. Let it get to the completion. Awesome. Let's look at the logs. The log says did not receive expected message on topic process order. Okay, are there any more logs? Let's grow up and see. Yeah, we do get a log saying error validating message on topic process order. This is the message that specmatic has received where the key name is total amounts. And it says expected key named total amount was missing. We also get a message saying key name total amounts was unexpected. So yes, the test does help us in knowing whether our application has deviated from the spec or not. This was a quick overview on how to run contract tests against a service which talks to Google books of instance, using specmatic. These tests can be done locally, as well as as part of your CI pipeline to provide quick feedback early in the site.