Forum Discussion
ahart
11 years agoOccasional Contributor
Not that I expect any replies, but I thought I would share my progress on this in case it might help someone else:
I copied those ten steps described previously to a separate test case. I then added two test case level properties, one to define the operation to be invoked for the extract and one for the fetch.
Initially, I tried expanding these properties in the requests. However, I ran into a peculiarity: anywhere else in a groovy script where I used an XmlHolder and tried modifying the requests I would then get an error when the "$" character was encountered. Consequently, I was forced to eliminate all property expansions and do everything with Groovy scripts.
I do wonder if this is a known limitation: when you have properties in a request, e.g., ${myProperty}, you will always encounter this error, or is there something I'm not doing correctly?
So, now I have a startup script that uses DOM to delete all existing nodes under the <body> tag of the request and then rebuild it using the operations specified in the properties.
The original test case now contains a "Run TestCase" step where it sets up the properties, and then runs the new test case to initiate the extract, poll it until done, find out how many chunks are available, and then iterate through them fetching all chunks.
One other problem is that my original "Schema Compliance" assertions are failing because it expects the response
for the operation I used when I create them initially. So, I disabled them, and next I will have to see if they can be dynamically created when the module is invoked with a particular set of operations.
But, the goal of not replicating all these steps for every pair of extract/fetch operations has been accomplished. All I have to do is add similar "Run TestCase" steps for each web service operation that follows this pattern.
I copied those ten steps described previously to a separate test case. I then added two test case level properties, one to define the operation to be invoked for the extract and one for the fetch.
Initially, I tried expanding these properties in the requests. However, I ran into a peculiarity: anywhere else in a groovy script where I used an XmlHolder and tried modifying the requests I would then get an error when the "$" character was encountered. Consequently, I was forced to eliminate all property expansions and do everything with Groovy scripts.
I do wonder if this is a known limitation: when you have properties in a request, e.g., ${myProperty}, you will always encounter this error, or is there something I'm not doing correctly?
So, now I have a startup script that uses DOM to delete all existing nodes under the <body> tag of the request and then rebuild it using the operations specified in the properties.
The original test case now contains a "Run TestCase" step where it sets up the properties, and then runs the new test case to initiate the extract, poll it until done, find out how many chunks are available, and then iterate through them fetching all chunks.
One other problem is that my original "Schema Compliance" assertions are failing because it expects the response
for the operation I used when I create them initially. So, I disabled them, and next I will have to see if they can be dynamically created when the module is invoked with a particular set of operations.
But, the goal of not replicating all these steps for every pair of extract/fetch operations has been accomplished. All I have to do is add similar "Run TestCase" steps for each web service operation that follows this pattern.
Related Content
Recent Discussions
- 5 days agoemoya