HTTP Request assertion predicated on parameters and injecting URL components
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
HTTP Request assertion predicated on parameters and injecting URL components
Hello,
I was wondering if there was a way to create HTTP request test steps, but call them from a groovy script for example, and inject certain parts of the URL -- interupting the script on fail. For example, the domain, parameters, endpoint, etc. The idea behind this question (maybe I should be going about this another way) is to create re-usable HTTP requests as components in my scripts that do validation.
1. Test Step A is an HTTP request, with a collection of assertions: [Assertion A, Assertion B, Assertion C . . ] preloaded
2. Test Step B (perhaps in another test case) is a groovy script that wants to fire an HTTP request using Test Step A, but also inject certain parameters, so the following request is made,
http://service.my/endpoint?Param1=true&Param2=false
3. Test Step C might want to change the domain,
http://service.your/endpoint?Param1=true&Param2=false
Finally, I was wondering if there was a feature that would populate assertions only if a given parameter or combination of parameters were present.
Thanks!
- Labels:
-
Test Results
-
Test Setup
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
This sounds more like a functional (data-driven) test. If you have the licensed version of ReadyAPI, assuming you do if you posting here and not SoapUI, then look up https://support.smartbear.com/readyapi/docs/functional/intro/index.html.
You can then use Excel to store the params for each scenario and use the same test request step.
IMHO, this is the standout feature of ReadyAPI.
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ahh, thank you for your response!
I've been looking at the documentation and will continue to do so -- but I'm wondering about the strategy you described.
a. An excel resource file for each different parameter value pair combination
b. A template HTTP request test step reads the file, fires the request, and contains all assertions related to the endpoint, applies assertions based on the subset of parameters present
Is this similar to what you're describing?
All the best,
-Mdar
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, exactly that.
The datasource does not only have to contain the parameters, it can hold anything.
In my data-driven tests, I typically have the parameters and expected results, for a given scenario, in a single row in Excel.
Once I've used the parameters in the request, I can then check the actual results against the expected results (from Excel) using a Groovy script step or you could use them in a simple assert on the request step itself.
