TDD (test driven development) and BDD (behavior driven development) are unique software development techniques that differ in what they are testing and how they are testing it. Despite their similar names, they serve distinct purposes. What Is TDD? TDD stands for test...
How to perform API testing in DesignWise
This tutorial will describe how DesignWise benefits can be delivered in API testing with 2 examples from CRUD operations.
- improved defect prevention,
- time savings, and
- better coverage understanding.
Clients often experience these benefits first with their functional UI testing projects. It can take more time for teams to realize that those same benefits apply to API testing as well. So, in this article, we will demonstrate how the tool can be used to optimize API testing with a couple of examples. While all of the above benefits remain relevant, many API teams especially appreciate the improved testing thoroughness that DesignWise ensures.
As shown in the second use case below, when you leverage the tool to design your API scenarios, you won’t stop with a simple shallow test that confirms that it is possible to “retrieve a member’s profile”. You’ll always systematically generate far more robust and thorough tests that also verify that retrieving a member profile will work correctly regardless of the member enrollment plan type, effective status, delivery type, address format, or other characteristics a member happens to have.
Let’s start with the simpler testing objective – submitting a payment through an API like this that accepts card transactions for different types, currencies, amounts with/without discounts, etc.
The request structure for many POST operations clearly outlines parameter and value candidates:
This example can be expanded to support shipping and/or contact information alongside other payment aspects – just add those parameters to the model.
While the request body is lacking variety, we are more interested in what we are getting back – the ability to retrieve the member details correctly regardless of the member type, address format, other characteristics. So, we create the DesignWise model based on the important factors from the response structure, not the request one. The corresponding simplified scope could look like this:
For some parameters, the values are not obvious and come from the format differences instead of the content ones. Typical examples include:
- addresses (single line vs multi line instead of “123 XYZ Street” vs “345 ABC Drive”);
- dates (supporting both mm/dd/yyyy and dd/mm/yyyy formats, current or future terms instead of arbitrary “4/5/2021” vs “5/4/2021”);
- E.g., “Term Effective Date” parameter above would have value expansions for formats.
- numbers (on top of any boundary conditions and rules, the validation of zero/N decimal spots should be considered).
Value expansions often play a “test data specifier” role in such models, as they contain actual text strings used in execution. However, such strategy may not be efficient for all types from the maintenance perspective.
Hardcoding “1/6/2022” as “current” substitute will work for 1 day. For the execution to continue, it will need to be updated and re-exported regularly. Instead, we recommend keeping such values at the abstract level in DesignWise and having functions in the execution framework to replace them at runtime.
The remaining question – how the script would work when we can’t put all these details into the request body. The following sequence will need to be followed:
- Find the record in the target system that meets the parameterized criteria for a given scenario;
- Collect the record ID;
- Pass it in the GET request;
- Validate the response against the parameterized criteria.
If the record does not exist, POST and GET could be tested in tandem from the same DesignWise model.
Side note: In some cases, the variety of the data you retrieve is limited by the vendor or other conditions. Therefore, identifying individual parameters and letting the DesignWise algorithm run “freely” lead to the numerous combinations that cannot be created/obtained.
While you could try to mimic the test data restrictions with DesignWise constraints, the more efficient method would be to perform the import on Forced Interactions screen combined with 1-way mixed-strength. And you would still get the benefit of one-to-many scripting during export.
“PUT” and “PATCH” methods can be modeled similar to “POST”, but you should consider two groups of DesignWise parameters – group 1 reflecting the initial state and group 2 reflecting what group 1 is being changed to. “DELETE” is similar to “GET”.
When it comes to the transition from DesignWise to the execution framework like Ranorex, there are a couple of export options:
- Only the data table in JSON/CSV format;
- Gherkin scripts;
- Custom scripts tailored to your tool pipeline.