 Hello and welcome to this demo about how we can stop database dependencies with specmatic JDBC stuff. In this example, we see a mobile application making a request to a backend API. The application code inside the API in turn calls a data source which leverages a JDBC driver to communicate with a database instance. Once the data is returned from the database, the results are processed by the application code and returned to the mobile application. Now, in order to test this API, we need to isolate it from its database dependency. For that, the first step is to switch out the data source with a specmatic data source. This enables the API to talk to the specmatic JDBC stuff instead of the real database. Now, we can easily run any type of test without having to depend on a complex DB setup. And for the purpose of this demo, I will be running a specmatic contract test based on the open API specification of the API. First, the test needs to set expectations with the specmatic JDBC stuff to let it know about the queries that it can expect and the data that it needs to respond with. Now, these expectations could be written by hand or could be recorded based on the actual interactions between the API and a real database. Once the expectations have been recorded, we do not have the necessary for the database in the test setup anymore. Now, specmatic will be able to leverage the open API specification of the API itself and generate contractors. The contract test makes HTTP request to the application, which now talks to the specmatic data source and specmatic data source itself responds with the data that has already been set up with it. To the application, when it receives the result set, it looks like it is talking to the real database. And thereby, it processes it as usual and returns it to the specmatic contractors, which now verifies if the response is according to the schema described in the open API specification. Let us take a look at all of this with a code example. This example application provides a cred wrapper on top of a product entity. In its production configuration, it is set up to talk to a real database based on these spring properties. Now, I'd like to contract test this application based on its open API specification, which is right here. It has two routes, one for creating products and another for updating products. To learn more about how we can leverage API specifications as contractors with specmatic, do watch our other videos. However, here is a quick overview. In the specmatic.json configuration, I'm pointing specmatic to the open API specification, which I just showed. And in the contract test, I'm providing specmatic with the coordinates of the application where it is running. In order to run this test, I need to isolate the application from its database dependency. And for that, I am disabling the data source auto configuration. What this does is completely remove the data source setup, which means there is no way for the application to talk to the real database. Let us ascertain that by running the test. And as expected, the test fails, because the application is unable to start up. Since the product repository cannot be instantiated, because the data source itself is not available. Now, let us provide it with a data source. And for that, first, I'm going to add the specmatic JDBC dependency to this application. And next, in the test configuration, I'm going to set up a bean for the data source itself. The data source bean is set up based on the JDBC stuff factory provided by specmatic. This takes two parameters. One is the port. And the other is the directory where the expectations are stored. The expectations, as I mentioned earlier, are nothing but mappings of queries and their responses. Here is an example of a select query, and for which we expect a single row to be coming back as a response. There are a bunch of such expectations that we have here. Now, let's run this contract test and see how it works. While the contract tests are running, let me also clarify that I'm creating this data source bean manually to make it easier to explain. However, if you have a spring application, you could very well leverage the spring auto configuration by using the specmatic JDBC spring dependency and adding the corresponding properties in your test property file. Now the tests have passed. Now let us look at what happens when the specmatic JDBC stub receives a query that it is not expecting. And for that, let me delete one of these expectations, which is for the insert query, which creates the product. And let me run the test again. And as expected, the create product test fails, because specmatic JDBC stub received a query that it was not expecting. And you can see the error here. And that is how we can test our applications by isolating them from the database dependencies by leveraging specmatic JDBC stub.