As most readers of this blog already know, I've just finished writing Building Web APIs with ASP.NET Core, a book dedicated to Web APIs built with the ASP.NET Core framework using REST and GraphQL. However, this time I want to talk about a different book - that I didn't write - which could well be an ideal continuation of mine.
I'm talking about Testing Web APIs, by Mark Winterigham, which - as the name implies - is all about finding a viable and uniform strategy to test our existing Web API projects.
Having just finished writing a full book related to Web API, I must say that reading this book was quite a blast: with all the topics I had to cover in my book - ASP.NET Core, Minimal API, DBMS, Entity Framework, Authentication, Authorization, GraphQL, and so on, not to mention the release & deployment parts - I didn't have much time left to deal with testing... and that's precisely the missing piece covered by this book.
And I can't imagine a better coverage than what I have found on these pages: Mark does not only does a wonderful job explaining the importance of testing (the first chapter, Why and How we test Web APIs, is mostly about that) but helps the reader to build up with a fully-fledged testing plan based upon one of the most useful and innovative microservice testing platform I have ever seen: Pact.io.
For those who never heard about Pact.io, we're talking about a code-first tool for testing HTTP and message integrations using contract tests. Which leads to another good question: what is contract testing?
In a nutshell, contract testing is a technique that can be used to test an integration point by checking each application in isolation to ensure the messages it sends or receives conforms to a shared understanding that is documented in a "contract". For Web APIs, the contract typically consists of the sum of the HTTP request and response cycle used by the client (consumer) and the server (provider or producer) to exchange data, as well as the architecture and interface used to standardize the protocol (REST), and the data format (JSON).
In Pact.io, any contract between a provider and a consumer is called a "pact": each pact is basically a collection of integrations, each one of them describing (for HTTP):
- An expected Request. In other words, what the consumer is expected to send to the provider.
- A minimal expected Response. What the provider is expected to return.
Given this premise, the "consumer test" has basically the role to check the answer to the following question: "assuming the provider returns response Y for request X, does the consumer code generate such a request? And is it capable of properly handling that response?"
This brief introduction to Pact.io should be enough to give you an idea of what we're talking about: for additional info, check out Pact's official docs or check out this introductory video:
That said, Mark's book doesn't limit to introducing Pact and explaining how to use it. In Testing Web APIs you will also learn how to design and implement a web API testing strategy, as well as set up a test automation suite, facilitate collaborative discussions to test web API designs, and much more!
I have also liked a lot the risk-based (Mark calls it risk-driven) approach to API testing, which is the key to safety and quality - especially if we use that same approach as a guiding light for coding, release, and deployment, which is what I also recommend in my book. I'm glad to see that such a pivotal concept of API security goes beyond the framework choice and the source code development, embracing also the release, deployment, and testing: it's definitely a great way to integrate some fundamental DevSecOps processes and best practices into our way of designing and building web apps.
Conclusions
All in all, I have found Testing Web APIs to be quite a unique and practical API testing guide, and an ideal read for those who want to deliver flawless Web APIs without getting swamped by custom, manual, and potentially useless (or incomplete) API testing processes.
