ContributionsMost RecentMost LikesSolutionsCredentials for Schema Compliance Assertion I am using the SoapUI Pro Maven plugin to run a project created in ReadyAPI 2.1.0. I've just added some Schema Compliance assertions to some of my SOAP requests, and they are failing to load the WSDL/XSD from the URL specified in the assertion configuration because the service URL uses Basic authentication. I am using the Maven POM to pass in credentials for my SOAP requests, and I'd like to use these same credentials for the Schema Compliance assertion. Anyone know of a way to do this? Thanks, David 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. Re: Improvement suggestions for property scoping Thanks, will do. Did not know about that area of the site. -David P. Improvement suggestions 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. SolvedRe: REST Request keeps changing, does not save correctly I had a similar problem with ReadyAPI 1.9 where script TestSteps would sporadically not save the work I had done. I updated to ReadyAPI 2.0 and this issue is still present. Is this a known issue as well? Property expansions failing in Maven, but working in UI I have 2 JDBC steps that contain assertions with a property expansion. The properties are expanded correctly in the GUI, but when I run the project on the Maven plugin, they evaluate to '[]'. I.e. they are not being expanded, and as a result my build fails. I have at least 1,000 property expansions all over my project referencing properties at all levels (Project, Suite, Case...), but these are the only 2 that are failing, and I have no idea why. I've tried changing the property locations from Test Case to Test Suite, tried changing the assertion from XPath to Message Content, and I cannot figure out why this is happening for just these 2. This is not the first time I've had a situation like this, where something runs correctly in the UI, but fails in Maven for reasons unknown. Anyone experienced this issue and know how to resolve it? Thanks, David