Forum Discussion
- deepesh_jainFrequent ContributorHi,
When you send a SOAP Response, you generally get a SOAP Response. Now this SOAP Response can either be a SOAP Fault or could be NOT SOAP FAULT. What SOAP FAULT means is that there is some issue(s) with the request XML you sent and it differs from the structure / format from the acceptable one as defined with schema. For example, if schema defines that following is an acceptable XML structure:
<A>
....<B>
........<C>
........</C>
....</B>
</A>
however you send the following XML structure in request, you will get a SOAP FAULT by the software that is doing that validation:
<A>
....<C>
........<B>
........</B>
....</C>
</A>
SOAP Fault is still a SOAP Response but it tells users that there is a "Fault" in the request that was sent.
Let me know if you need more information.
Thanks,
Deepesh Jain - ABCDEFGContributorThank you for the reply.
Yes, I need more lights in to this.
1]Are you saying that SOAP Fault, Not SOAP Fault Assertions are validating the Requests and not on Response received?
2] Whats a SOAP Fault? Whats is a NOT SOAP Fault? [I know these all are assertions in soapUI, I need beyond that]
3] Can you brief with any example which differentiate each other?
SOAP Fault, Not SOAP Fault - each success and failure scenarios.
For Ref: Sample WSDL -
http://www.oorsprong.org/websamples.cou ... e.wso?WSDL
Example
Request
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:web="http://www.oorsprong.org/websamples.countryinfo">
<soapenv:Header/>
<soapenv:Body>
<web:CapitalCity>
<web:sCountryISOCode>USA</web:sCountryISOCode>
</web:CapitalCity>
</soapenv:Body>
</soapenv:Envelope>
Response
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<web:CapitalCityResponse xmlns:web="http://www.oorsprong.org/websamples.countryinfo">
<web:CapitalCityResult>Washington</m:CapitalCityResult>
</web:CapitalCityResponse>
</soap:Body>
</soap:Envelope>
^Regards - deepesh_jainFrequent ContributorWell, in your original post you didn't talk anything about assertions. These assertions do validate only the responses not the requests. If you are looking to what these different assertions do, here is the updated response:
1. SOAP RESPONSE : This assertion validates that the response received is actually a SOAP RESPONSE. Unless your webservice is down or something, you should always get this passed. If not, that means the response timed out and you didnt get a soap response. For example, how you sometimes get "Page cannot be displayed" when the web page is not available. Same concept
2. SOAP FAULT : This assertion will validate that the SOAP Response that you got is actually a SOAP FAULT. For example, you might have sent an incorrect xml as a part of your test case and you are expecting that you would get a SOAP FAULT. In this case, you would have SOAP FAULT as your assertion. SOAP FAULT assertion will PASS your test case if you get SOAP FAULT in response.
3. NOT SOAP FAULT : This is exactly opposite to the one above. If you do expect a valid SOAP RESPONSE, you would place this assertion, and this assertion will PASS your test case in case it gets a valid SOAP RESPONSE. If you placed this assertion, but in case you get a SOAP FAULT in your response, this assertion will fail the test case.
With the example request and response you sent, the response if you notice is a good SOAP response and is not a SOAP FAULT. So for that particular response if you include both SOAP FAULT and NOT SOAP FAULT assertion, the former would FAIL while the latter will PASS.
Hope this helps.
Regards,
Deepesh Jain - ABCDEFGContributorHi Deepesh,
Thank you for the reply. The level of information is good :-)
However, I need more information towards difference of both...
For Ex: if we put both SOAP FAULT & NOT SOAP FAULT assertions in a method and runs, we may get 4 cases...
Case 1. [SOAP Fault Fail and Not SOAP Fault Success]
Case 2. [SOAP Fault Success and Not SOAP Fault Fail]
Case 3. [SOAP Fault Success and Not SOAP Fault Success]
Case 3. [SOAP Fault Fail and Not SOAP Fault Fail]
qn1. Can you please analyse above 4 cases and provide reasons?
qn2. Whether SOAP Fault and Not SOAP Fault are reverse of one another?
qn3. Do we need both these assertions really? since, SOAP Fault failure means Not SOAP Fault Success and vice versa.
^Thanks - deepesh_jainFrequent ContributorWrong, you will only have case 1 and 2.
SOAP FAULT and NOT SOAP FAULT are basically opposite of each other. If you put both the assertions one is bound to fail as both of them will validate the response for
1. SOAP FAULT
2. NOT SOAP FAULT
You obviously cannot have both in the same SOAP step response. - ABCDEFGContributorGood. We are in same point.
if they are Opposite to each other, whats the purpose of having Both assertions?
Because [one Fails => other success] -> So what purpose it serves?
We need only 1 assertion right? Either SOAP FAULT or NOT SOAP FAULT.
^Thanks - deepesh_jainFrequent ContributorWrong. Remember that SOAPUI is a testing tool and you can automate your whole test bed. So you might have two test cases with different expected result:
1. Test Case 1 - Input parameters such that the expected result is SOAP FAULT.
2. Test Case 2 - Input parameters such that the expected result is NOT SOAP FAULT and is a valid response.
Since you would want all your test cases to pass. You need to apply SOAP FAULT assertion in the first test case to validate that the response is indeed a SOAP Fault and NOT SOAP FAULT assertion to second test case to validate that the response is not a SOAP Fault.
Regards,
Deepesh Jain - ABCDEFGContributorThank you, Good response.
However, i don't understand it clearly. question is, if SOAP FAULT assertion is failed in one test case means, its not a soap fault.... right? - deepesh_jainFrequent ContributorCorrect. If you have a soap fault assertion and that fails it means you were expecting a soap fault but you got a valid reaponse which was NOT a soap fault.
Regards,
Deepesh jain - ABCDEFGContributorSo, if its not a soap fault implies 'NOT SOAP FAULT' Assertion is VALID, right?
^Thanks
Related Content
- 3 days ago
- 12 years ago
- 3 years ago
Recent Discussions
- 15 years ago