 Hi, in this video, we'll show you how to generate an API coverage report. Let's say we have an application which has a route getProducts by ID. We also have an open API specification in which this route is documented. Now Specmatic can leverage this open API specification as an executable contract and run contract tests against the application. If the implementation of the route matches the specification, then Specmatic will report the contract test as fast. Now what if we document a new path in the specification but fail to actually implement it in the application? Now any API consumers who use this spec will get a 404 error when they hit this unimplemented path. It could also happen that we add a new route in the application but fail to document it in the specification. The open API specification is now incomplete and it does not accurately describe the application's endpoints. An incomplete specification is a huge problem and has serious implications. Firstly, the effectiveness of our contract test is compromised. Secondly, any API consumers who use this spec will never become aware of the missing path. This will also impact those API consumers who wish to leverage this spec as a stub. We won't be able to detect API compatibility breakage. And finally, we won't be able to enforce organizational API standards using linters on the undocumented endpoints. This is exactly the problem that Specmatic's API coverage report solves. Specmatic can detect an application's endpoints and generate a comprehensive API coverage report. The API coverage report helps us to identify any mismatch between the open API specification and the application early in the development life cycle. We can also prevent these issues from propagating any further by failing the CI pipeline build if the API coverage report detects any mismatch. Here's a sample API coverage report. As you can see, it lists all the endpoints of the application. For every endpoint, it reports the coverage and also indicates if the endpoint is missing in the spec or not implemented in the application. Now, let's see this in a concrete example. Over here, we have a Spring Boot application with a bunch of controllers with routes implemented in them. We also have an open API specification for this app. And this is how it looks with all the endpoints described. Now, let's take a look at the contract test. The key thing to note in the contract test is the endpoint's API property, through which Specmatic will determine all the endpoints implemented in the app. For this, we use the mappings endpoint provided by the Spring Actuator Library. Let's try and run the test. OK, so we can see that there's one test which has failed and our build has failed as well. Let's take a look at the API coverage report. This is the API coverage report. It lists all the endpoints with their methods and response codes. It also reports how many times was a particular endpoint called during the test execution. We can see that there are three main issues identified over here. The slash health endpoint is missing in the spec. The get method of the product slash ID endpoint is also missing in the spec. And the product slash ID slash inventory endpoint is present in the specification but not implemented in the app. And we can see that the corresponding test for this endpoint has also failed. Scrolling below, we can see that the success criteria for the API coverage report has not been met. Now, let's take a closer look at this. The success criteria for the API coverage report can be defined in the Specmatic JSON file. Here, we have a report configuration section and here's where we define the success criteria. We can define a minimum overall API coverage required for the build to succeed. We can also specify the maximum number of endpoints that can be found missing in the specification. Specmatic will fail the build if either of these criteria are not met. With this background, let's go back to the API coverage report and let's try and fix these issues. Let's first try and implement this endpoint, which is present in the specification but not there in the app. So we go to the products controller and we add the implementation. Let's try and run the test. So this test, which was failing previously, has now passed. But our build is still failing because we haven't met the success criteria of the API coverage report. Our total API coverage is still 79%, whereas the threshold set is 100%. We still have two missing endpoints in the specification and the maximum threshold is zero. Let's take a look at this get method for the product slash ID endpoint, which is missing in the specification. So let's try and add it to the spec. We've added the get method to the spec. Let's try and run the test again. In the coverage report, we can now see that this get method is reported as covered. The build still fails because we still haven't met the success criteria. The API coverage now is 83%, still less in the threshold of 100% and we still have one missing endpoint in the specification. And that's the health endpoint. Now, it's quite possible you want to exclude certain monitoring endpoints like health and heartbeat from the coverage report. And we can do that from the specmatics config file. So we go to the report configuration section and we add the URL in the excluded endpoints array. Let's try and run the test again. Great. So we have all tests passing. The API coverage is 100% and there are no missing endpoints in the specification. Hence, we have met the success criteria of the API coverage report and our build has passed as well. So we can see how the API coverage report helps us ensure that the open API specification accurately describes our application. The open API coverage report is not only available for Spring Boot apps in Java, but also for projects in Node and Python.