Proposal: Add additional methods to RequestResult#28
Proposal: Add additional methods to RequestResult#28zdimension wants to merge 4 commits intomainfrom
Conversation
- deserialize_body: Deserializes the body without performing checks on status code or content. - ensure_status_ignore_body: Checks the status code while ignoring body. - expect_status_ignore_body: Checks the status code while ignoring body, panic on failure. - ensure_empty_body: Checks that the body is empty. - ensure_status_empty_body: Checks the status code and the emptiness of the body. - expect_status_empty_body: Checks the status code and the emptiness of the body, panic on failure.
| @@ -180,15 +180,15 @@ pub async fn delete_user() { | |||
| CONTEXT | |||
| .run(&request) | |||
There was a problem hiding this comment.
could we try to use each new request at least once (so we can cover them a bit on "real life" tests)
There was a problem hiding this comment.
use each new request at least once
wdym? the request here (l. 178)
let request = Request::delete(path!["users", id]);is used twice (l. 181 & l. 189)
There was a problem hiding this comment.
I said request, I meant methods sorry (like deserialize_body, ensure_status_ignore_body, ...)
There was a problem hiding this comment.
ohh yes, of course, I'll add test cases for those!
| @@ -304,13 +304,53 @@ impl RequestResult { | |||
| /// | |||
There was a problem hiding this comment.
I appreciate this api because it allows us to use a basic command (ensure_status) to perform the meat of most of our needs, and have more specific commands.
Maybe it can mean that ensure_status could be renamed to reflect the 2 things it does, maybe it's not needed, not sure about that.
2 participants
This PR adds the following methods to
RequestResult:deserialize_body: Deserializes the body without performing checks on status code or content.ensure_status_ignore_body: Checks the status code while ignoring body.expect_status_ignore_body: Checks the status code while ignoring body, panic on failure.ensure_empty_body: Checks that the body is empty.ensure_status_empty_body: Checks the status code and the emptiness of the body.expect_status_empty_body: Checks the status code and the emptiness of the body, panic on failure.The last two items, specifically, are an attempt to fix #25 while both
ensure_* -> Result) and panic (expect_* -> Either<(), !>) versions of the corresponding methodsAny criticism on the API structure in itself would be much appreciated.
ensure_thing1_thing2rather than a builder pattern (.ensure_thing1().ensure_thing2())? The latter, if chosen, would require breaking the current API sinceexpect_statusshould then only check for status, not body as currently is the case.