Functional API testing in its nutshell is calling methods of your API with some input parameters in some specific order and comparing the actual output with the one, which you expect for the provided parameter and call sequence.
To ensure the API quality, you typically would want to evaluate it with lots of combinations of parameters – both valid and invalid – which can hardly be performed manually. This is a place where the data-driven testing (DDT) strategy may naturally come into play. This strategy separates data (sets of parameters and predicted responses) from the test logic, and it is perfect for being automated.
An automated data-driven test always includes these two components:
A loop through a data source — data can be prepared beforehand and stored in Excel spreadsheets, DB tables, CSV files, etc., or generated on-the-fly.
A parameterized functional test within the loop, where data from the source is fed to requests and automated assertions.
The first question you would probably ask is ‘how to prepare data for my data-driven test’. There are several approaches to this:
Prepare data manually. The resulting set can have various data to address typical and edge usage scenarios. But, this approach requires a lot of time and efforts, as well as good understanding of the API business logic.
Generate synthetic data based on some patterns. This can be performed relatively easily with some special tools (at that, you can generate a data set as large as you need), though, the integrity of data is not guaranteed.
Get production data. Such data is truly realistic, diversified, and consistent, but, in some cases, it cannot be provided to the QA team due to privacy concerns, or, if it can, someone needs to care about obfuscating sensitive data before using it as test data.
Whatever approach or combination of approaches you choose, here are the types of data sets your DDT should typically include to ensure a good coverage:
Values of invalid types (e.g., specify a string in a field, where an integer is expected).
Empty values for required fields.
Values, exceeding the limits, including extremely large values.
Invalid combinations of values (e.g., an “end date” is before a “start date”).
In conclusion, the decision on whether to use or not to use data-driven testing depends on your specific situation and business requirements. But, generally, an automated DDT test with thoroughly and competently prepared testing data allows quickly testing your API using a huge number of input data combinations, which guarantees that your API is ready to be used in our real “data-driven” world.