Page History
...
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.
| 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.
...
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 TCD quickly generates the scenarios:
Side note:
| Info |
|---|
| 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 Test Case Designer model with that one parameter wouldn’t make sense, right? Yes and no.
...
If the record does not exist, POST and GET could be tested in tandem from the same TCD model.Side note:
| 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 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 TCD applicability to non-UI types of testing.
...