Page History
...
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 also apply to API testing as well. While all of the above benefits remain relevant, many API teams especially appreciate the improved testing thoroughness that Test Case Designer 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”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 havehas.
| Table of Contents |
|---|
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.
...
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 TCD model could look like this:
...
This example can be expanded to support shipping and/or contact information alongside other payment aspects – just add those parameters to the model.
...
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 Test Case Designer model with that one parameter wouldn’t make sense, right? Yes and no.
While the request body is lacking lacks 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 Test Case Designer model based on the important factors from the response structure, not the request one. The corresponding simplified scope could look like this:
...
- 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., the “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 an execution.
However, such strategy may not be efficient for all value types from the maintenance perspective. Hardcoding “1/6/2022” as the “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 TCD 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 Test Case Designer model. Just remember to look at consider both request and response variables, both mandatory and optional ones, and think about the core underlying variation for each.
The remaining question – is how the script would work works when we can’t put all these details into the request body. The following sequence will need to be followed:
...
| Info |
|---|
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 Test Case Designer algorithm run “freely” lead to the numerous combinations that cannot be created/obtained. While you could try to mimic the test data restrictions with TCD constraints, the more efficient method would be to perform the import on the Forced Interactions screen combined with 1-way mixed-strength. And you would still get the benefit of one-to-many scripting during export. |
...
Hopefully, this article clarified a few perceived challenges about regarding TCD applicability to non-UI types of testing.
“PUT” and “PATCH” methods can be modeled similar similarly to “POST”. Still, but you should consider two groups of TCD parameters – group 1 reflecting the initial state and group 2 reflecting what group 1 is being changed to. “DELETE” is similar to “GET”“GET.”
When it comes to the transition from Test Case Designer to the an automated execution framework like Ranorex, there are a couple of export options:
...