API endpoints make websites work. Simply put, they are the conduits that data moves through. Login functionality? Frequently an API call for authentication. Click into a new section of a webpage? Often an API call for content. Clearly, APIs are a critically important part of any web application. The way that we test these endpoints is incredibly important. At API Fortress, we like to maintain the best practices that follow for effective API testing.
Rule 1: Keep it DRY
DRY is an acronym for “Don’t Repeat Yourself.” This simple idea forms a core principle of good programming. When we are writing tests, even in API Fortress’ visual composer, we’re still programming and should make every effort to adhere to the principles of writing good code. Let’s say that I have an endpoint that provides user data. The relational database providing the user data has ten entries, and I’d like to write tests to validate the responses when each one of these entries is called. There’s no “All Users” route as our organization has no real business need for one. The only way to access the data in each of these endpoints is to send multiple calls, one for each entry in the database. How could we accomplish this without repeating code?
The non-DRY solution to this problem would be to write the request and assertions for each individual user in the user endpoint. This would work, of course. However, if we’re talking about an endpoint with ten entries, we’re talking about writing the same test ten separate times. If we have 5 assertions in the basic test structure, we’re going to be looking at 50 individual assertions.
How can we make this test DRY-compliant? Well, we know that the schema across all users should match. If the schema is the same, then the assertions to validate that schema should also be the same. Instead of rewriting the same test over and over again, we can leverage a loop component from API Fortress and iterate over each user in the endpoint. We can pass the list of users as a static dataset (CSV, XML, JSON, etc.) and reference each user without manually rewriting our test. Now our test is nice and DRY.
Rule 2: Make Your Intentions Clear
Rule 1 (Keep it DRY) is an easily defined technical rule. Rule 2 is a bit murkier. When writing API tests, it’s important to make your intentions clear so that the next person to use this test knows exactly why you wrote it. This can be done in a number of ways. First, leveraging comment components in API Fortress allows us to make our intentions very clear by writing them out in plaintext. Well documented code is a big part of communicating intent.
Rule 3: Treat the API You’re Testing Like A Consumer Would
If you’re testing an API, be certain to treat it exactly as the consumer would. Sometimes in the course of writing test suites we focus too much on what we know to be the proper response. In order to properly vet our API endpoints, we need to introduce the sort of errors that a user might introduce. For a moment, we need to take off our developer/tester hat and think like the user. After all, things rarely break in predictable ways in a live environment so it’s extremely important to test as if we’re already there.
Rule 4: Eliminate as Many Fixed Data Sources as Possible
In a live environment, API endpoints often rely on the output from other APIs. The only way to ensure that this relationship is intact is to create an integration test that calls the first API and then leverages the result of that call to hit the second API. When we begin testing the second API with static expected data from the first API, we are no longer testing the environment holistically. Wherever possible, we should be following actual user flows and creating integration tests rather than testing individual endpoints in a vacuum.
Testing is an integral part of the development cycle. Testing API endpoints is an extremely important part of a holistic testing strategy. Unit testing in a development environment is a great place to start, but without testing the interaction between endpoints in a staging or live setting, unforeseen issues can appear in a new release. The rules discussed here are certainly not the only things to consider when developing an API testing strategy, but they’re a great jumping off point. Keep testing!
API Fortress was specifically built for today’s agile architectures. A collaborative platform that bridges the gap between development, QA and DevOps. By collaborating using the simple GUI, teams can work together to create a series of powerful API test in one place. Then those tests can be executed at every stage of the lifecycle, in particular as part of the CI/CD process. Using our webhooks or Jenkins plugin, you can automatically execute tests and get notified of issues before the code is published live. The platform works in the cloud or on-premises, giving you the flexibility to run test from any environment while still satisfying security protocols. Catch errors before your customers find them and release code with confidence.
For other related articles, please check out API Fortress’s blog, here.