Forum Discussion

kbw's avatar
kbw
Contributor
9 years ago
Solved

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...
  • AntonE's avatar
    AntonE
    9 years ago

    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.

  • kbw's avatar
    kbw
    9 years ago

    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).

AntonE's avatar
AntonE
SmartBear Alumni (Retired)
9 years ago

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.

  • kbw's avatar
    kbw
    Contributor
    9 years ago

    Thanks Anton,

     

    I've tried it manually with the new more verbose 1.4.1 syntax and it did work that way.  Though, even in 4.1.1, right-clicking in the VirtResponse doesn't give the context menu entries for the new 1.4x feature for referencing all test suites--so you'd want to check on that too, when you look at adding the local references.

     

    I definitely wouldn't want to use the full path syntax as a work-around though.  It would mean that any time you copied a test case, to make a new test variation, you'd need to go into the VirtRestponse steps and manually change the references to point to the current test case.

     

    On a more theoretical note:

    I disagree with you on the usefuleness of having access to the test case and suite in a VirtResponse test step.  There are times when a VirtResponse test step needs to reference data that came in an earlier test step.  I prefer doing property expansions directly where they are needed, rather that property transfer steps, which add another test step to maintain. Direct property expansions are also better than property transfers when you need your target data to just be a portion of the destination field in the VirstResponse--currently we work around it using Groovy scripts to do the transfers.

    • AntonE's avatar
      AntonE
      SmartBear Alumni (Retired)
      9 years ago

      What I meant by "references to current test suites, test cases etc. don't make much sense for Virt" is that Virts, unlike test steps, don't belong to a particular test case or test suite - they exist on a project level, so to say. It does make sense for VirtResponse test step though, so I agree it would be useful to have such references in its editor. I think we should do this, too. Thank you for pointing this out.

       

      Old syntax for property expansion still exists, a new one was added mainly for getting properties from test cases and test suites other than current. But it didn't work for this test step in the firts place, so for now only new syntax works with VirtResponse test step.

      • kbw's avatar
        kbw
        Contributor
        9 years ago

        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).