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

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

5 Replies

Sort By
  • 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.

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

    I’ve reported this issue to our R&D team. Thanks for letting us know.