XQuery match returns success where failure expected

Question

I use a Xquery match assertion with a JDBC request

The response of the JDBC request:
<Results>
<ResultSet fetchSize="0"/>
</Results>

The declare section:
<Result>
{
for $x in //Row
order by $x/GEGEVENSGROEP
return <GEGEVENSGROEP>{data($x/GEGEVENSGROEP/text())}</GEGEVENSGROEP>
}
</Result>

The expected result:
<Result>
<GEGEVENSGROEP>ODBeroepsOnderwijs</GEGEVENSGROEP>
<GEGEVENSGROEP>ODHogerOnderwijs</GEGEVENSGROEP>
<GEGEVENSGROEP>ODVoortgezetOnderwijs</GEGEVENSGROEP>
<GEGEVENSGROEP>ORBeroepsOnderwijs</GEGEVENSGROEP>
<GEGEVENSGROEP>ORHogerOnderwijs</GEGEVENSGROEP>
<GEGEVENSGROEP>ORVoortgezetOnderwijs</GEGEVENSGROEP>
</Result>

In the 4.0.1 version of SoapUI this resulted in a failure. In the 4.5.0 version this resulted in a success situation. Can someone explain me why?

(In the good situation the expected result is:
<Results>
<ResultSet fetchSize="0">
<Row rowNumber="1">
<ID>42637</ID>
<VERSION>0</VERSION>
<DATUM_BEGIN>06/04/12</DATUM_BEGIN>
<DATUM_EINDE/>
<GEGEVENSGROEP>ODBeroepsOnderwijs</GEGEVENSGROEP>
<LAATSTE_SIGNALERING/>
<BAT_ID>22516</BAT_ID>
<ID>22516</ID>
<VERSION>1</VERSION>
<AANDUIDING_TYPE>persoon</AANDUIDING_TYPE>
<IDENTIFICATIE_ID>222235796</IDENTIFICATIE_ID>
<DATUM_BEGIN>06/04/12</DATUM_BEGIN>
<DATUM_EINDE/>
<LAATSTE_SIGNALERING/>
<STM_ID>42</STM_ID>
<ID>42</ID>
<VERSION>0</VERSION>
<BESTEMMING_SIGNALERING>HOI</BESTEMMING_SIGNALERING>
<NAAM>HOI_VOOROPL</NAAM>
</Row>
<Row rowNumber="2">
<ID>42638</ID>
<VERSION>0</VERSION>
<DATUM_BEGIN>06/04/12</DATUM_BEGIN>
<DATUM_EINDE/>
<GEGEVENSGROEP>ODHogerOnderwijs</GEGEVENSGROEP>
<LAATSTE_SIGNALERING/>
<BAT_ID>22516</BAT_ID>
<ID>22516</ID>
<VERSION>1</VERSION>
<AANDUIDING_TYPE>persoon</AANDUIDING_TYPE>
<IDENTIFICATIE_ID>222235796</IDENTIFICATIE_ID>
<DATUM_BEGIN>06/04/12</DATUM_BEGIN>
<DATUM_EINDE/>
<LAATSTE_SIGNALERING/>
<STM_ID>42</STM_ID>
<ID>42</ID>
<VERSION>0</VERSION>
<BESTEMMING_SIGNALERING>HOI</BESTEMMING_SIGNALERING>
<NAAM>HOI_VOOROPL</NAAM>
</Row>
<Row rowNumber="3">
<ID>42636</ID>
<VERSION>0</VERSION>
<DATUM_BEGIN>06/04/12</DATUM_BEGIN>
<DATUM_EINDE/>
<GEGEVENSGROEP>ODVoortgezetOnderwijs</GEGEVENSGROEP>
<LAATSTE_SIGNALERING/>
<BAT_ID>22516</BAT_ID>
<ID>22516</ID>
<VERSION>1</VERSION>
<AANDUIDING_TYPE>persoon</AANDUIDING_TYPE>
<IDENTIFICATIE_ID>222235796</IDENTIFICATIE_ID>
<DATUM_BEGIN>06/04/12</DATUM_BEGIN>
<DATUM_EINDE/>
<LAATSTE_SIGNALERING/>
<STM_ID>42</STM_ID>
<ID>42</ID>
<VERSION>0</VERSION>
<BESTEMMING_SIGNALERING>HOI</BESTEMMING_SIGNALERING>
<NAAM>HOI_VOOROPL</NAAM>
</Row>
<Row rowNumber="4">
<ID>42634</ID>
<VERSION>0</VERSION>
<DATUM_BEGIN>06/04/12</DATUM_BEGIN>
<DATUM_EINDE/>
<GEGEVENSGROEP>ORBeroepsOnderwijs</GEGEVENSGROEP>
<LAATSTE_SIGNALERING/>
<BAT_ID>22516</BAT_ID>
<ID>22516</ID>
<VERSION>1</VERSION>
<AANDUIDING_TYPE>persoon</AANDUIDING_TYPE>
<IDENTIFICATIE_ID>222235796</IDENTIFICATIE_ID>
<DATUM_BEGIN>06/04/12</DATUM_BEGIN>
<DATUM_EINDE/>
<LAATSTE_SIGNALERING/>
<STM_ID>42</STM_ID>
<ID>42</ID>
<VERSION>0</VERSION>
<BESTEMMING_SIGNALERING>HOI</BESTEMMING_SIGNALERING>
<NAAM>HOI_VOOROPL</NAAM>
</Row>
<Row rowNumber="5">
<ID>42635</ID>
<VERSION>0</VERSION>
<DATUM_BEGIN>06/04/12</DATUM_BEGIN>
<DATUM_EINDE/>
<GEGEVENSGROEP>ORHogerOnderwijs</GEGEVENSGROEP>
<LAATSTE_SIGNALERING/>
<BAT_ID>22516</BAT_ID>
<ID>22516</ID>
<VERSION>1</VERSION>
<AANDUIDING_TYPE>persoon</AANDUIDING_TYPE>
<IDENTIFICATIE_ID>222235796</IDENTIFICATIE_ID>
<DATUM_BEGIN>06/04/12</DATUM_BEGIN>
<DATUM_EINDE/>
<LAATSTE_SIGNALERING/>
<STM_ID>42</STM_ID>
<ID>42</ID>
<VERSION>0</VERSION>
<BESTEMMING_SIGNALERING>HOI</BESTEMMING_SIGNALERING>
<NAAM>HOI_VOOROPL</NAAM>
</Row>
<Row rowNumber="6">
<ID>42633</ID>
<VERSION>0</VERSION>
<DATUM_BEGIN>06/04/12</DATUM_BEGIN>
<DATUM_EINDE/>
<GEGEVENSGROEP>ORVoortgezetOnderwijs</GEGEVENSGROEP>
<LAATSTE_SIGNALERING/>
<BAT_ID>22516</BAT_ID>
<ID>22516</ID>
<VERSION>1</VERSION>
<AANDUIDING_TYPE>persoon</AANDUIDING_TYPE>
<IDENTIFICATIE_ID>222235796</IDENTIFICATIE_ID>
<DATUM_BEGIN>06/04/12</DATUM_BEGIN>
<DATUM_EINDE/>
<LAATSTE_SIGNALERING/>
<STM_ID>42</STM_ID>
<ID>42</ID>
<VERSION>0</VERSION>
<BESTEMMING_SIGNALERING>HOI</BESTEMMING_SIGNALERING>
<NAAM>HOI_VOOROPL</NAAM>
</Row>
</ResultSet>
</Results>
)

euthenia · Answer

I have also experienced a problem with the XQuery Match. Mine was as an assertion on the response from a web service call - the call returned a SOAP fault rather than the expected response that the XQueryMatch has been configured to look for. Rather than failing, the test step passed.

I'm going to have to revert back to soapUI 4.0.1 because of this issue.

Regards,
Ed

jamesw · Answer

I'm seeing this problem in 4.5 free, pro, and the pro nightly build.This is a show stopper for me. Has anyone at SmartBear reproduced thisJ

globus1987 · Answer

I wrote about it too when beta came out.

mayurnath · Answer

I have a similar issue where I put a XPath assertion which will fail. I call my SoapUI project from command line using testRunner and I have no indication of failure which is bad for me since I am writing a wrapper on top of my SoapUI projects to automate my testing.
Anyone find an alternative solution to this problem

Forum Discussion

XQuery match returns success where failure expected

Recent Discussions

Windows installation <user>

Automation for SignalingService

Unable to see receive MQTT message in response

Related Content

successful case

Expected error logs show success logs without any events instead, how come?

The Secrets of Successful Collaboration - BDD