-
Notifications
You must be signed in to change notification settings - Fork 6
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
Add record and playback #30
Comments
Looks like a very interesting feature to add to stubr. I planned to do it anyway sometimes as this is already something supported by Wiremock. |
Hi @nirvdrum, stubr record
# with httpie
http jsonplaceholder.typicode.com/users --proxy http://localhost:3030
# you'll find a stub in 'jsonplaceholder.typicode.com/users-9658470615814157994.json' Then for playback you just have to start the recorded stubs with stubr like I hope you'll like. I'll let this issue open so that you can give me some feedback: what you'd like to add to it etc.. I have my owns ideas but I'd rather have yours. Anyway it was fun to implement and has given me a lot of ideas regarding how I can improve stubr. |
@beltram Thanks for pulling this together! Unfortunately, I've since left the project that could have benefited from this. I'll try to pull together something a bit smaller locally so I can try it out and provide any feedback. |
One HTTP testing technique I've used with other languages & libraries is a record and playback feature. E.g., the VCR in Ruby can intercept HTTP calls from the client and either pass them through to the upstream service, serializing the request and response to YAML files (cassettes), or prevent remote access and returning deserialized response objects form already recorded cassettes, if the request object matches.
This approach strikes a nice balance between full integration tests that constantly access a remote service and mocking implementations, which try to approximate the response coming from a remote service. As long as the remote service is reasonably stable, it's typically okay to assume when given the same request, you'd get back the same response. If that assumption ever breaks, you can just discard the old recording and re-run it again. Such tests are also good at catching changes made from the client... if the request object ever changes, it will fail to match a previously found recording and the test would fail with an error indicating no recording could be found.
Rust can't quite handle this at the client level like VCR can in Ruby, but I think a mock server like stubr can take the same basic approach. When configured in record mode, it'd function as a reverse proxy and serialize the HTTP request and response into some recording file format. When configured in playback mode, it would disable the reverse proxy -- preventing access to the remote service -- but still return responses if a recording already exsits, which should be completely transparent to the client.
The text was updated successfully, but these errors were encountered: