Defect: VirtResponse test steps have no visibility to their own test case, suite or sibling steps
VirtResponse test steps have no xpath visibility to any of the following objects:
- The VirtResponse's own Test Suite
- The VirtResponse's own Test Case
- The VirtResponse' own sibling steps in the same test case
This is a long standing issue, even before Ready API--we've had to find creative ways to work around it in the past. It also affects Ready API 1.4.1 as well--the new feature for accessing properties anywhere in the project didn't affect VirtResponses.
Steps to Reproduce:
1. Create a test case that contains a SOAP Request test step and SOAP VirtResponse step
2. VirtResponse step, response pane, right click, and mouse over the Get Data menu item
3. For comparison, in the Request step, request pane, do the same
Expected:
In both step 2 and 3, we expect to see the Project, Test Suite, Test Case and sibling tests (along with other items, and in 1.4.1 you should see all test suites)
Actual:
You only get the expected list of objects from the request step. The VirtReponse step ONLY shows the following items:
- Project
- Virt
- VirtResponse
You CANNOT work around this by hand-writing the property expantions. Anything that the Get Data UI can't see, hand-written property expansions also can't operate on.
See attached screenshots.
You are right, unfortunately, now we don't have test step, test case or test suite items in Get Data for VirtResponse. We should add them in next releases.
But, actually, you can hand-write the property expansions in VirtResponse. You should use the new syntax we've introduced in 1.4 - the "full path" to properties, rather than references to current test suites, test cases etc. (which don't have much sense for Virt anyway). For example: ${#[TestSuite 1]#prop} or ${#[Yahoo Weather TestSuite#Virt TestCase#REST Request]#Response}. Look here for the details: http://readyapi.smartbear.com/features/expansions/syntax.
Ah yes, I agree with you on that, thanks for your clarification.
So looks like the underlying issue is that the VirtResponses are essentially getting their visibility from the parent Virt class, instead being given test step specific Get Data access. The Get Data options in test Steps are the same as the options given in ServiceV Virt editors (plus they act weird when using them from test steps--e.g. Choosing Create New from the Virt option creates a property, but then there's noplace at all to see or manage the property for the VirstResponse step).