LukeMathWalker / LukeMathWalker/wiremock-rs
Is it possible to assert on received request?
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 799
- Forks
- 91
- PR merge metrics
- No merged PRs in 30d
Description
Hi! I would like to assert on the received request body of a mock, but can't figure out how to acheive this.
To illustrate, let's say that I want to verify that a specific mock has received a request body that matches:
```json
{
"foo": "bar"
}
```
I tried to do this with Matchers:
```rust
let expected_body = json!({ "foo": "bar" });
wiremock::Mock::given(method("POST"))
.and(wiremock::matchers::path("/foo"))
.and(body_json(expected_body));
```
, but it seems that the mock now simply returns 404 if the body doesn't match. This does fail the test, but it fails it in a very subtle way. I would like for my tests to fail more explicitly with a message like "Mock received incorrect body ..." from `assert_eq!`.
I tried creating my custom Matcher that asserts on the body, but then I realized that since the mock runs in a totally separate process from the tests, this will just crash the mock server, which fails the test in an arguably even more subtle way.
I could check `MockServer::received_requests`, but this returns all requests for the entire test, which means that I have to somehow figure out which request was received by which mock.
Is there a better way to acheive this that I'm missing?
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing MockServer::received_requests, body_json, and the custom Matcher behavior described in the issue. Determine how a request can be associated with a specific mock and how an assertion failure can be reported back to the test process; done means incorrect request bodies produce an explicit test failure rather than a 404 or server crash.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- testing
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100