How We Use StopLight.io to Test 233 API Endpoints in Seconds

SendGrid actively supports SDKs across 7 programming languages, with each of these SDKs supporting 233 API calls. We needed a way to test each endpoint, ensuring we don’t break basic usability while rapidly evolving our code base to support all of our new v3 APIs, without creating custom mocking code in each testing framework.

StopLight.io made this extremely easy with its Prism mock server, giving us a Swagger/OAI-driven mocked version of the SendGrid API server. In this post, we will describe the specific workflows that allow us to test all of our endpoint interfaces in seconds rather than minutes.

The first stop on this journey is the StopLight.io documentation tools. For us, this was the most tedious part of our challenge, as we had 233 API calls to document. However, we were able to speed up this process dramatically by using StopLight.io’s discovery tools. We simply proxied through StopLight.io and browsed around SendGrid.com and StopLight.io automatically began documenting our endpoints. Then we used the StopLight.io API Design tools, depicted below, to refine our definitions.

Once we completed the documentation with our final touches, using the pleasurable interface references above, we were able to export a Swagger/OAI definition of our API with the click of a button.

For example, here is a snippet of the SendGrid Swagger/OAI definition that highlights the GET call on our /user/webhooks/parse/settings endpoint (Imagine having to write and manage this, especially at scale!):

Next, we created an SDK automator in-house (stay tuned, we will explore this topic in a future post) that builds documentation, examples, and test API calls for all of the endpoints across all 7 SDKs using the StopLight.io generated Swagger/OAI definition. These tests simply make an API call and checks for a correct response. Without Prism, we would have needed to mock all of those calls.

Here is what creating a basic mock server looks like in Java, and this is not even a realistic example as we still need to define all the expected responses based on the incoming endpoint and its parameters:

After installing Prism and pointing it to our Swagger/OAI file, we were able to run our local tests against a local mocked server and their hosted StopLight.io service.

Today, we can have code like the following for our tests, without needing to create a custom mock function, making it very easy to do a quick system health check across all of our endpoints and SDKs:

Even with all this progress, there was still one more problem! Within Travis CI, we were using the hosted StopLight.io service for the 233+ tests. With so many tests, this was taking longer than we would like and unnecessarily taxing StopLight.io’s servers.

So, Tom, StopLight.io Engineer, once again demonstrated outstanding customer service and created a script that automatically installs Prism onto Travis CI, runs the mocked server, executes the tests and then shuts down the server. This also works locally with the added benefit of automatically determining the appropriate version of Prism for your OS, allowing you to get your development testing environment up and running without even a single click.

Now that we have an easy way to mock out a SendGrid server, the door is open to other use cases, such as the ability to mock out your interface to SendGrid and perform all of your integration testing and prototyping before using a single SendGrid credit.

We would love to learn how you are planning to use the ability to mock out SendGrid’s API servers. Share with us on Twitter, LinkedIn, or Facebook.