Chapter 16 gotchas
There’s a few things to watch out for when using
- Security: Don’t put your secure API keys, tokens, etc. on the public web. See the Security chapter (13)
- API key issues: Running vcr enabled tests in different contexts when API keys are used can have some rough edges. See (13.2)
- Dates: Be careful when using dates in tests with
vcr. e.g. if you generate todays date, and pass that in to a function in your package that uses that date for an HTTP request, the date will be different from the one in the matching cassette, causing a
- HTTP errors: It’s a good idea to test failure behavior of a web service in your test suite. Sometimes
vcrcan handle that and sometimes it cannot. Open any issues about this because ideally i think
vcrcould handle all cases of HTTP failures.
- Very large response bodies: A few things about large response bodies. First,
vcrmay give you trouble with very large response bodies as we’ve see yaml parsing problems already. Second, large response bodies means large cassettes on disk - so just be aware of the file size if that’s something that matters to you. Third, large response bodies will take longer to load into R, so you may still have a multi second test run even though the test is using a cached HTTP response.
- Encoding: We haven’t dealt with encoding much yet at all, so we’re likely to run into encoding issues. One blunt instrument for this for now is to set
preserve_exact_body_bytes = TRUEwhen running
vcr::insert_cassette(), which stores the response body as base64.
- devtools::check vs. devtools::test: See (7.4.1)
- ignored files: See (15)
16.1 Correct line identification
To get the actual lines where failures occur, you can wrap the
test_that block in a
OR put the
use_cassette() block on the inside, but make sure to put
testthat expectations outside of
Do not wrap the
use_cassette() block inside your
test_that() block with
testthat expectations inside the
use_cassette() block, as you’ll only get the line number that the
use_cassette() block starts on on failures.