 Hi. In this video, we'll show you how to mock JMS using Spectmatic. Let's take the example of a consumer which makes a request to an application. The request is received by the controller, which in turn invokes the service layer. The service layer fetches data from a domain service or an HTTP dependency, and then drops a message on to a JMS queue, say something like ActiveMQ. Finally, the service layer responds back to the controller, which in turn responds back to the consumer. Now, to test this application in isolation, we take an async ABS specification, which describes the JMS queue, and the schema of the messages that it is expected to receive. And we mock it out using Spectmatic's JMS mock. With the JMS mock now in place, we can run contract tests against the application. Let's see how we do this. First, we set expectations on the JMS mock, describing the messages that it is expected to receive. Then, we also set expectations on Spectmatic's HTTP stub, which uses the open API specification for the application's HTTP dependency or the domain service. Now, if you wish to learn more about contract tests and how to stub out HTTP dependencies using open API specifications and Spectmatic, please check out other videos on this channel. Finally, Spectmatic uses the application's open API specification to run contract tests against it. Every contract test results in a request being sent to the application, which is received by the controller. The controller invokes the service layer, which in turn fetches the data now from Spectmatic's HTTP stub, and then drops a message onto Spectmatic's JMS mock. When the JMS mock receives a message, it validates the message against the schema defined in the Async API specification. If the message does not match the schema, then it will fail the test. The JMS mock has an in-memory active MQ broker, and so the service layer can communicate with it quite seamlessly just like it would with a real-time JMS queue in production. Finally, the service layer responds back to the controller, which in turn responds back to the contract test. When all contract tests are executed, Spectmatic calls the JMS mock to validate the messages that it has received. Now, let's see this in a concrete example. Over here, we have a service layer which fetches data from a domain service or an HTTP dependency, and then sends messages to a JMS queue. Let's take a look at the Spectmatic.json file of this application. Over here, we provide an Async API specification for the application's JMS dependency, and open API specification for the application's HTTP dependency or the domain service, and also an open API specification for the application itself, which Spectmatic will use to run contract tests. Since we are talking about JMS, let's have a look at the Async API specification. We've defined a queue name product queries, and this is the schema of the messages that it is expected to receive. Let's now take a look at the contract tests. In the contract tests, we first set the host and the port which Spectmatic will use to run contract tests against the application. Then we specify an endpoints API which Spectmatic will use to determine the routes exposed by this application. For this, we use the mappings endpoint provided by the Spring actuator library. Now, if you look at the controllers in this application, we can see that there are two routes defined over here. Spectmatic will use this information to generate a covered summary report, which we shall see shortly. Going back to the contract tests. Next, we create the JMS mock and set expectations on it. So what we are saying here is that we expect that a queue named product queries will receive three messages on it. Next, we create the HTTP stub, set expectations on it, start the application and run the tests. After all contract tests are executed, we check if the expectations set on the JMS mock are met. To do this, we call the verify expectations method. The verify expectations method will assert that the product queries queue received exactly three messages and all three messages match the schema defined in the specification. If either of these conditions are not met, the verify expectations method will report errors. With this background, let's try and run the contract tests. Great. So all contract tests have passed. Let's take a look at the covering summary report. As we saw before, there are two routes defined in the application. But since in the open APS specification of this application, there is only one route defined. Hence, we see only one route is reported with status covered, while the other one is reported with status missed. Let's now take a look at the API tests. So in this class, we have tests to validate each of the routes defined in the application. This is the test in which we expect messages on the JMS mock. So we start by setting expectations on the JMS mock, similar to what we saw in the contract test. So we expect three messages on the product queries queue. We then set expectations on the HTTP stub. We invoke the API or route. We validate the response. And then we assert if the expectations set on the JMS mock are met by calling the verify expectations method, similar to the way we did it in the contract test. We also further assert the actual message received by JMS mock by calling the object message received on channel method, as described here. With this background, let's try and run the API tests. Great. So all the API tests have passed as well. The JMS mock is wire compatible and can be controlled entirely from within the test. Hence, you can run this test locally or also as part of your continuous integration build to provide quick feedback early in the cycle.