This tutorial will describe how DesignWise benefits can be delivered in API testing with 2 examples from CRUD operations.
This article explains how DesignWise can be used to improve API testing. As a quick reminder of our applicability guidelines and standard benefits – if a system or process contains several decision points and at least 2 steps with multiple options per step, then DesignWise can be used to achieve the benefits of:
- 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.
POST
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:
To limit the scope for example purposes, let’s say we act as a vendor with 90% of payments coming from North America and from the 4 major card networks. Further, the discount is driven by the amount alone being higher than 100 (regardless of the currency). With those assumptions, the initiation of your DesignWise model could look like this:
Value expansions cover card types and currencies we rarely experience in production. They also add extra variety to the amounts for boundary and format testing. We can then add this rule – “Amount[with discount] <-> Discount[“-10.00”]”- and see how DesignWise quickly generates the scenarios:
Side note: Keep in mind that only value expansions are populated in the export (not “value – value expansion” syntax), so they won’t interfere with the scripting for execution – i.e. the csv table or the Automate script would have only “100.00”, not “100.00 – without discount – medium”.
This example can be expanded to support shipping and/or contact information alongside other payment aspects – just add those parameters to the model.
GET
Now let’s talk about the trickier objective – testing the API that retrieves the details of the insurance policyholder. The request body often contains just one field – Member ID. So, building a DesignWise model with that one parameter wouldn’t make sense, right? Yes and no.
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.
For any CRUD operation type, you can also consider adding the “environmental” variables such as the channel the request is sent from, versioning of the protocol, etc. You can see the draft generated scenarios below:
Typically, the data dictionary section in the API documentation provides a great start to building the DesignWise model. Just remember to look at both request and response variables, both mandatory and optional ones, and think about the core underlying variation for each.
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.
Conclusion
Hopefully, this article clarified a few perceived challenges about DesignWise applicability to non-UI types of testing.
“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.