Within this guide, you will get access to a checklist. This checklist will cover the types of tests that I would expect any API developer to include in their application 🖥️. Ensuring your API has good test automation is an essential step in any project, however, not all developers feel comfortable writing tests. Developers new to testing often feel overwhelmed when deciding what types of tests they need to write for their applications. The aim of this guide is to help developers who are struggling to decide on the types of tests they need to include within their API projects. If you have been tasked with writing integration tests, read on, to learn more 💥💥💥

Test automation can be split into two camps, unit tests and integration tests. Getting good unit test code coverage is easy enough. There are lots of available software on the market that will help you achieved this. Static code analysers, like Codacy, or SonarQube can be integrated within your codebase. These tools can monitor your codebase and report on code coverage. When you know your code has high code coverage (say over 80%) you can usually have confidence that the software does what it is meant to. Unfortunately, when it comes to API and integration testing, things are not always as simple 😢.

If your application contains features that require a number of APIs to be called successfully in order for a task to complete, using a tool to report on code coverage will not tell you if you have written tests that cover every scenario. This type of testing is often referred to as integration, or, end-to-end (E2E) testing. The developers who understand the code will need to use good judgment when deciding what end-to-end tests to write. An example E2E test within an e-commerce store might add a product to the basket, submitting their order details including credit card information and then asserting that a successful transaction occurs.

Before we get to the checklist, I should state the writing tests is not a one time gig. When working with software things change. How an API works will never be set in stone. Your endpoints will likely interact with lots of other systems which can also change. This is what automation testing is not a one-time thing. Writing automation tests is a never-ending journey, where new tests should be written whenever the code is updated. From my experience, it is better to write tests as you create and amend code rather than leave testing as an activity that you lead until the end of the project ⚠️

End-to-end Checklist

The below checklist provides a high-level checklist about the types of tests that you should write:

  • Check the response type is correct, e.g. GET, POST, PUT and DELETE, etc...

  • Validate a least one happy and one sad path, e.g. response codes are either 200, 404, 401, etc...

  • Validate that any HTTP headers you expect are set

  • Validate that there is no missing data in the response body

  • Validate response contains everything you expect

  • Validate any max/min limits by testing the largest and lowest value range for all input parameters

  • Check for invalid verbs

  • Validate what happens when invalid parameter type data is submitted, e.g. submitting numbers within data fields

  • Validate API response times are within a certain threshold

  • Validate all data paths on any APIs that contain if/switch cases

  • Validate authorization headers exist

  • Validate what happens when authorization headers are not present

  • Validate any potential CORs issues

  • Load testing. Use a tool like JMeter to ensure the API works when called under load

  • Validate cache headers are set

  • Validate API warm-up within an acceptable threshold

  • Validate what happens in a timeout situation

  • Validate what happens when a third-party system is down

  • Validate race condition tests/async tests

This list covers all the different types of tests that you need to write.

Happy Coding 🤘

-