Writing down what I think I understood
In all cases a good package structure seems to help, e.g. in your blog post example having crGET() makes things easier.
Also, if one wants to test the exact same function calls in two situations (server up, server down), one might need to play with .mockPaths().
Writing down what I think I understood
Your blog post. How exactly did you create https://github.com/Crunch-io/rcrunch/blob/d1b5cade5e7b0608ddc1ce5de1a576e2d3614d84/tests/testthat/app.crunch.io/503.R? I.e. what did you have to guess?
Use
capture_requests(, simplify = FALSE)with a call that works. This way you get a fixture with the right filepath, and with all fields. Edit the fixture, replacecapture_request()withwith_mock_api(). (that's what I did).To guess the filepath, the easiest solution is otherwise to run the test with
with_mock_apiwhen the mock file doesn't exist, because the error message contains the mock filepath. (this is explained in the blog post)Mocking httr functions https://github.com/cran/datapackage.r/blob/0bc1caa1903cf36b2d5f318265426eb072c361d7/tests/testthat/test-profile.R#L68 that's closer to what webmockr would let one do, actually. I.e. not writing the fake to file.
In all cases a good package structure seems to help, e.g. in your blog post example having
crGET()makes things easier.Also, if one wants to test the exact same function calls in two situations (server up, server down), one might need to play with .mockPaths().