I ran into one of those bugs that makes you question reality.
Everything looked fine in SoapUI. The endpoint was correct, properties were set, requests looked clean. Yet in Jenkins, the same testcases kept failing with ModelItem errors, dreaded NullPointerExceptions, and HTTP 500 responses.
So I did the usual:
- checked connectivity → fine
- tested with curl → also HTTP 500, but with a valid response
- verified the endpoint → reachable
- compared local vs build → same request
At this point it really looked like a backend issue.
But then things got weird.
Running the same test in SoapUI GUI showed the exact same HTTP 500… yet the testcase didn’t fail. The Maven plugin, however, treated it as a hard failure and stopped immediately.
HUH?!?!
That sent me digging deeper.
I was this close to just disabling the failing teststeps. But then something caught my eye in the testcase properties.
Wait… is that the OLD property name?
Yes. It is.
Can I edit it here? Nope.
Would it still use that value even though I had already overwritten it in the testcase?
Maybe…
Alright. Close SoapUI. Open the XML. Search. Replace.
Is this the smoking gun?
Restart SoapUI. Rerun the failing step.
HTTP 200.
…wait what?! Success??
Commit. Push. Let Jenkins run.
Build: SUCCESS.
The property had been renamed at some point, but not everywhere. SoapUI happily showed the “correct” value in the UI, while parts of the project were still using the old one.
SoapUI 5.9.1 itself would happily show everything as green, even though the initial request ended in an HTTP 500.
Meanwhile, the SoapUI Maven plugin would hard fail on that same response.
So depending on where the request originated, it was built differently — and depending on the toolset, the outcome differed too.
Same test. Same environment. Completely different result.
Brain lesson learned:
Always grep the XML.