16 Contributor friendliness
How do you make your package wrapping an HTTP resource contributor-friendly?
rOpenSci has some general advice on contributor-friendliness.
Now, there are some more aspects when dealing with HTTP testing.
16.1 Taking notes about encryption
In your contributing guide, make sure you note how you e.g. created an encrypted token for the tests. Link to a script that one could run to re-create it. Good for future contributors including yourself!
16.2 Providing a sandbox
It might be very neat to provide a sandbox, even if just for yourself.
- If interacting with say Twitter API you might want to create a Twitter account dedicated to this.
And this is why you don’t use live API credentials in your tests 🤣. Leaving up for the humorous replies https://t.co/x0COfvt2QD
— Hadley Wickham (@hadleywickham) February 27, 2021
If interacting with some sort of web platform you might want to create an account special for storing test data.
Some web APIs provide a test API key, a test account that one can request access to.
Make sure to take notes on how to create / request access to a sandbox, in your contributing guide.
16.3 Switching between accounts depending on the development mode
Your package might have some behaviour to load a default token for instance, placed in an app dir. Now, for testing, you might want it to load another token, and you probably also want the token choice to be as automatic as possible.
The rtweet package has such logic.
is_testing <- function() {
identical(Sys.getenv("TESTTHAT"), "true")
}
is_dev_mode <- function() {
exists(".__DEVTOOLS__", .getNamespace("rtweet"))
}- If some environment variables are present it is able to create a testing token.
rtweet_test <- function() {
access_token <- Sys.getenv("RTWEET_ACCESS_TOKEN")
access_secret <- Sys.getenv("RTWEET_ACCESS_SECRET")
if (identical(access_token, "") || identical(access_secret, "")) {
return()
}
rtweet_bot(
"7rX1CfEYOjrtZenmBhjljPzO3",
"rM3HOLDqmjWzr9UN4cvscchlkFprPNNg99zJJU5R8iYtpC0P0q",
access_token,
access_secret
)
}