Description
Following a recent Twitter discussion between @gavinbarron and Chris Johnson on this topic, we should consider adding a page to our Wiki in the Background information section to explain the position of using the proxy alongside other testing approaches to help inform developers of the value add from a testing perspective.
Chris: Why this vs. a unit test? It would have thought simulating errors etc should be part of a test suite? This seems good for dev quick play, but not for full dev cycle?
Gavin : Great question!
Unit test should absolutely be part of your testing suite. This allows you to simulate failures in your running application. Everything from 404s and 429s to 507s.
It's a lot easier to understand a failure case when you can trigger it on demand.
Chris: I guess when running an app, loaded up with usage, and being able to introduce errors would be helpful. For things like testing your code when the APIs return 429s etc. I usually build a test that exercises those scenarios vs. running the whole app.
Gavin: Depending on your codebase, in some cases mocking an http response with a specific status and body can be very hard.
I remember it being a collosal yak shaving effort when we were using RestSharp as our Http request library.
Chris: for sure. but to know you don't break your error handling etc. you gotta shave dem damn yaks! Now, shipping a test graph client lib (to simulate errors on demand from tests) would really really help.