The docs assume you are using testthat for your unit tests.
use_vcr
You can then set up your package to use vcr
with:
vcr::use_vcr()
This will:
vcr
into the DESCRIPTION
testthat
is setuptestthat
if nottests/fixtures
vcr
vcr
.gitattributes
file with settings for vcr
./tests/testthat/helper-vcr.R
fileWhat you will see in the R console:
◉ Using package: vcr.example ◉ assuming fixtures at: tests/fixtures ✓ Adding vcr to Suggests field in DESCRIPTION ✓ Creating directory: ./tests/testthat ◉ Looking for testthat.R file or similar ✓ tests/testthat.R: added ✓ Adding vcr config to tests/testthat/helper-vcr.example.R ✓ Adding example test file tests/testthat/test-vcr_example.R ✓ .gitattributes: added ◉ Learn more about `vcr`: https://books.ropensci.org/http-testing/
Secrets often turn up in API work. A common example is an API key.
vcr
saves responses from APIs as YAML files, and this will include your secrets unless you indicate to vcr
what they are and how to protect them.
The vcr_configure
function has the filter_sensitive_data
argument function for just this situation.
The filter_sensitive_data
argument takes a named list where the name of the list is the string that will be used in the recorded cassettes instead of the secret, which is the list item.
vcr
will manage the replacement of that for you, so all you need to do is to edit your helper-vcr.R
file like this:
library("vcr") # *Required* as vcr is set up on loading invisible(vcr::vcr_configure( dir = "../fixtures" )) vcr::check_cassette_names()
Use the filter_sensitive_data
argument in the vcr_configure
function to show vcr
how to keep your secret. The best way to store secret information is to have it in a .Renviron
file. Assuming that that is already in place, supply a named list to the filter_sensitive_data
argument.
library("vcr") invisible(vcr::vcr_configure( filter_sensitive_data = list("<<<my_api_key>>>" = Sys.getenv('APIKEY')), # add this dir = "../fixtures" )) vcr::check_cassette_names()
Notice we wrote Sys.getenv('APIKEY')
and not the API key directly, otherwise you'd have written your API key to a file that might end up in a public repo.
The will get your secret information from the environment, and make sure that whenever vcr
records a new cassette, it will replace the secret information with <<<my_api_key>>>
. You can find out more about this in the HTTP testing book chapter on security.
The addition of the line above will instruct vcr
to replace any string in cassettes it records that are equivalent to your string which is stored as the APIKEY
environmental variable with the masking string <<<my_api_key>>>
. In practice, you might get a YAML
that looks a little like this:
http_interactions: - request: method: post ... headers: Accept: application/json, text/xml, application/xml, */* Content-Type: application/json api-key: <<<my_api_key>>> ...
Here, my APIKEY
environmental variable would have been stored as the api-key
value, but vcr
has realised this and recorded the string <<<my_api_key>>>
instead.
Once the cassette is recorded, vcr
no longer needs the API key as no real requests will be made.
Furthermore, as by default requests matching does not include the API key, things will work.
Now, how to ensure tests work in the absence of a real API key?
E.g. to have tests pass on continuous integration for external pull requests to your code repository.
tests/testthat/helper-vcr.R
)if (!nzchar(Sys.getenv("APIKEY"))) { Sys.setenv("APIKEY" = "foobar") }
.Renviron
A simple way to manage local environmental variables is to use an .Renviron
file.
Your .Renviron
file might look like this:
APIKEY="mytotallysecretkey"
You can have this set at a project or user level, and usethis
has the usethis::edit_r_environ()
function to help edit the file.
Add the following code to your website.
For more information on customizing the embed code, read Embedding Snippets.