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
Improvement: Make WebMock ignore the last slash (/) in URLs #864
Comments
Isn’t the flip side to this that you could have a passing test but code the fails in production because of extra or missing / that would be equally hard to spot? |
@fcheung That would happen if the server treats If the fear of this tripping up people is a problem though, perhaps this option could be enabled as a configuration option set during initialization? All of this is a longwinded way of saying: how can we help programmers quickly spot the difference between two nearly identical HTTP requests that WebMock outputs? In cases of a missing |
I agree though please take into account that often Rails apps are only clients of externals API's, non-Rails API's and WebMock is to verify the usage of these API's. I'm not really sure how many API's treat trailing slash or lack of it as the same endpoint. I acknowledge bot your @KelseyDH and @fcheung points. Perhaps WebMock should suggest adding or removing the missing slash in case it spots that this is the only difference? |
A common mistake when testing API's is accidentally including a
/
in a url in one place, while omitting that/
in another endpoint. Effectively the endpoint works, yet WebMock will say they are different.E.g. writing
www.example.com/foo
inassert_requested
when the actual API hitshttp://example.com/foo/
. When POSTing to an endpoint with parameters, this imperceptible difference is easy to miss and can lead to many hours of frustration as developers parse the long comparison output between the two requests to figure out what they did wrong in their API call versus the test case.My suggestion is that WebMock treats URL's ending in
/
the same as urls without the last slash. For those wanting the old behaviour, the gem could add a flag to reenable it for the few oddball projects actually treating calls tohttp://example.com/foo/
andhttp://example.com/foo
differently.The text was updated successfully, but these errors were encountered: