Forum Discussion
turman
13 years agoOccasional Contributor
Hi,
I have solved my problem, in fact I was confusing because I was thinking that the regexp token defined in the "Contains" assertion dialog was something to find in the content of the service's response. But that's not the case, that regexp token is something that must match with the content.
In fact the "problem" is that SoapUI uses String.matches() for regexp which is just a convenience method :
I find it by looking into the SoapUI code but I really should have read the documentation before because in that example it was almost suggested
But IMHO using the regex token as something to find (instead of something to match with) is much more natural, specially in the "Contains" assertion context. I'll try a pull request for that in github
I have solved my problem, in fact I was confusing because I was thinking that the regexp token defined in the "Contains" assertion dialog was something to find in the content of the service's response. But that's not the case, that regexp token is something that must match with the content.
In fact the "problem" is that SoapUI uses String.matches() for regexp which is just a convenience method :
stackoverflow wrote: str.matches(regex) behaves like Pattern.matches(regex, str) which attempts to match the entire input sequence against the pattern and returns true if, and only if, the entire input sequence matches this matcher's pattern
Whereas matcher.find() attempts to find the next subsequence of the input sequence that matches the pattern and returns true if, and only if, a subsequence of the input sequence matches this matcher's pattern
I find it by looking into the SoapUI code but I really should have read the documentation before because in that example it was almost suggested
But IMHO using the regex token as something to find (instead of something to match with) is much more natural, specially in the "Contains" assertion context. I'll try a pull request for that in github
