Skip to content
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

Allow MockRest to match header/queryParam value list with one Matcher #29964

Closed
github-actions bot opened this issue Feb 13, 2023 · 0 comments
Closed

Allow MockRest to match header/queryParam value list with one Matcher #29964

github-actions bot opened this issue Feb 13, 2023 · 0 comments
Assignees
Labels
in: test Issues in the test module in: web Issues in web modules (web, webmvc, webflux, websocket) type: backport An issue that is a backport of another issue to a maintenance branch type: enhancement A general enhancement
Milestone

Comments

@github-actions
Copy link
Contributor

github-actions bot commented Feb 13, 2023

Backport of gh-29953

@github-actions github-actions bot added in: test Issues in the test module in: web Issues in web modules (web, webmvc, webflux, websocket) status: superseded An issue that has been superseded by another type: backport An issue that is a backport of another issue to a maintenance branch type: enhancement A general enhancement labels Feb 13, 2023
@github-actions github-actions bot added this to the 5.3.26 milestone Feb 13, 2023
@simonbasle simonbasle removed the status: superseded An issue that has been superseded by another label Feb 13, 2023
@simonbasle simonbasle changed the title Add support in MockRestServiceServer to assert ALL header and queryParam values with a single Matcher Allow MockRest to match header/queryParam value list with one Matcher Feb 13, 2023
simonbasle added a commit that referenced this issue Feb 13, 2023
This commit adds a `header` variant and a `queryParam` variant to the
`MockRestRequestMatchers` API which take a single `Matcher` over the
list of values.

Contrary to the vararg variants, the whole list is evaluated and the
caller can choose the desired semantics using readily-available iterable
matchers like `everyItem`, `hasItems`, `hasSize`, `contains` or
`containsInAnyOrder`...

The fact that the previous variants don't strictly check the size of the
actual list == the number of provided matchers or expected values is
now documented in their respective javadocs.

See gh-29953
Closes gh-29964
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) type: backport An issue that is a backport of another issue to a maintenance branch type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants