Page History

This tutorial will describe how DesignWise benefits can be delivered in article explains how Test Case Designer can be used to improve 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 TCD can be used to achieve the benefits of:

...

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 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”. 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.

...

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 TCD 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 TCD 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 Test Case Designer 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 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:

...

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 TCD and having functions in the execution framework to replace them at runtime.

...

Typically, the data dictionary section in the API documentation provides a great start to building the DesignWise Test Case Designer 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.

...

If the record does not exist, POST and GET could be tested in tandem from the same DesignWise planTCD 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 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 DesignWise TCD 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 TCD 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 TCD 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 Test Case Designer to the automated execution framework like Ranorex, there are a couple of export options:

...