A combinatorial explosion can occur when all possible combinations of all input parameters of a system are tested. When the number of input parameters and their possible values increase, the number of tests needed to cover each new case increases exponentially. Combinatorial interaction testing (CIT) is a black-box testing technique used to avoid a combinatorial explosion. CIT finds errors that are triggered by the interactions between parameters. One of the so-called combination strategies that can be used for CIT is t-wise testing. T-wise testing requires at least one test case for each combination of any t parameter values where t is the chosen strength - the number of parameters amongst which the interactions are tested. In this report, CIT with t-wise testing is applied to the testing of REST APIs.
The thesis examines how 1-wise, 2-wise and 3-wise interaction testing compare when it comes to detecting injected faults in the code of REST APIs. It also studies the effectiveness of the three t-way combinations in terms of run-time. The questions were examined through three API endpoints where the 1-wise, 2-wise and 3-wise test suites were generated directly from their OpenAPI specification. These test suites were constructed with parameter values in accordance with boundary value analysis and equivalence class partitioning. To answer the questions of this study, mutation testing was used as a means of injecting faults into the system under test. The mutants were developed specifically for this study as the input validation of the affected APIs was done through code annotations of which there are not many established mutants. The results of this study show that 1-wise, 2-wise and 3-wise testing of REST APIs all detect the same injected faults when performing mutation testing on the test suites. Furthermore, it showed that the run-time of the test suites increases significantly as the strength of t-wise testing increases. However, these results are limited to this particular study and cannot be assumed to coincide with other REST APIs since only three endpoints were examined. To further strengthen this conclusion, possible future work is suggested.