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.

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.

...

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.

...

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.

...