dpasotti's avatar
dpasotti
Occasional Contributor
7 years ago
Status:
New Idea

Improvements for property scoping

I just discovered here the source of my frustration and confusion over why my tests weren't passing: property scoping. I was trying to access a property defined in 'TestCase1' from 'TestCase2.' I understand why this should not be done and why this property should be stored or transferred at the parent TestSuite level, but I have several suggestions for improvement here:

 

1.) The main reason I used properties in this manner is that they were available to me using the "Get Data" feature. If properties are outside the scope of the current test step/case/suite, I would suggest adding some logic to the Get Data feature to make them unavailable for selection by the user.

 

2.) In the UI, this type of scoping rule is NOT enforced. This means that I can build my tests in SoapUI NG using this type of property reference across scope boundaries, and the tests pass. I then move these same tests to the Maven plugin and they fail, leaving me very confused. I would suggest making these types of "illegal" property references fail in the UI like they should according to the link above. That way a test developer knows upfront something is wrong before moving the tests to Maven or whatever the next phase may be.

 

Thanks!

David P.

1 Comment

  • kbw's avatar
    kbw
    Contributor

    In older versions of SoapUI property expansions were limited to be within the test case or it's direct ancestors (suite, project, and global).  So, they acted the way you describe wanting them to act.

     

    However, in more recent versions, SmartBear has enhanced property expansions to be able to get data from any property in the project, whether it's in a direct ancestor or not.  This is NOT an illegal reference (even though I agree with you that it generally isn't necessarily a wise reference).

     

    If the Maven plugin had issues with your expansions, then what you hit was actually a bug in the Maven plugin, not a ReadyAPI bug.