Skip to content

Why MockMvcResultMatchers has not a xpath method with org.hamcrest.Matcher<T>? [SPR-13687] #18262

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
spring-projects-issues opened this issue Nov 14, 2015 · 4 comments
Assignees
Labels
in: test Issues in the test module in: web Issues in web modules (web, webmvc, webflux, websocket) status: declined A suggestion or change that we don't feel we should currently apply type: enhancement A general enhancement

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Nov 14, 2015

Manuel Jordan opened SPR-13687 and commented

Hello

Just curious and in a someway confused.

If the MockMvcResultMatchers class has the jsonPath method with the following signatures:

  • jsonPath(String expression, org.hamcrest.Matcher<T> matcher)
  • jsonPath(String expression, Object... args)

And the xpath method with the following signatures:

  • xpath(String expression, Map<String,String> namespaces, Object... args)
  • xpath(String expression, Object... args)

Why does not exist?

  • xpath(String expression, org.hamcrest.Matcher<T> matcher)

I think very valuable use hamcrest for XML too.


Affects: 4.2 GA

Issue Links:

@spring-projects-issues
Copy link
Collaborator Author

Rossen Stoyanchev commented

The two jsonPath methods pretty much cover the options in JsonPathResultMatchers. The XpathResultMatchers on the other hand has more overloaded options, so the two xpath methods in MockMvcResultMatchers gather only the common input, and then you have to do "." and pick the option you want.

That said a shortcut for xpath(String expression, org.hamcrest.Matcher<T> matcher) should be okay to provide.

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

Having a quick look at this, wouldn't we need overloaded methods for String/number/boolean matchers, in order to delegate to XpathResultMatchers?

Let's rather target this for 4.3 instead.

Juergen

@spring-projects-issues
Copy link
Collaborator Author

Manuel Jordan commented

Thanks a lot by your support.

@spring-projects-issues
Copy link
Collaborator Author

Rossen Stoyanchev commented

On taking a closer look, I recall now why it's set up this way. It's the difference between the JsonPath and XPath support. If you look at XpathExpectationsHelper you'll see what it takes to invoke it. We already expose all the available options.

@spring-projects-issues spring-projects-issues added status: declined A suggestion or change that we don't feel we should currently apply in: test Issues in the test module type: enhancement A general enhancement in: web Issues in web modules (web, webmvc, webflux, websocket) labels Jan 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: test Issues in the test module in: web Issues in web modules (web, webmvc, webflux, websocket) status: declined A suggestion or change that we don't feel we should currently apply type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants