My son loves Legos. He is continually fascinated about the ways he can use and reuse various Lego blocks to build different kinds of towers and other edifices. He also likes to use the same larger Lego blocks as a foundation for a multitude of different towers. Why should REST API testing be any different? Herein, I refer to two main patterns for REST API testing:
This is best explained by the code below. This code is in Groovy and represents these patterns but the patterns are applicable across languages. One functional test method and one performance test method is shown.
Regarding pattern #1, like building blocks that fit nicely together, each class is responsible for its own “separate concern”. When we separate out the behavior as shown, we prevent ourselves from repeating code needlessly across different tests. This leads to the tests having VERY FEW lines of code and being VERY READABLE.
Regarding pattern #2, there are many different types of performance testing but one thing this type of testing commonly necessitates is concurrent connections. This is often overlooked when test infrastructure is built around single request-response scenarios or utilizes some off-the-shelf tool that has a proprietary language that only one or a few on a team will understand. (As a side note here, I also strongly recommend the http client utilize non-blocking connections so that it isn’t using one thread per connection and thereby unable to scale to higher concurrency levels due to client resources skewing metrics.) Why not use the same code (read: Lego blocks) that was the foundation for the functional tests and apply that to the performance tests as well? Doing so nicely applies the DRY Principle to your test infrastructure. This pattern allows for continuously running performance tests that can be created quickly and which can provide metrics that can be captured in a database for reporting and trending purposes.