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.
  • 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"))
rtweet_test <- function() {
  access_token <- Sys.getenv("RTWEET_ACCESS_TOKEN")
  access_secret <- Sys.getenv("RTWEET_ACCESS_SECRET")
  if (identical(access_token, "") || identical(access_secret, "")) {


16.4 Documenting HTTP testing

Contributors to the package might not be familiar with the HTTP testing package(s) you use (this is true of any non-trivial test setup). Make sure your contributing guide mentions pre-requisites and link to resources (maybe even this very book?).