3

A drake workflow can have several custom functions stored in its R directory. It would make sense to develop unit tests for the custom functions. There is well-established tooling and structures for running testthat unit tests on an R package in RStudio (or from a command line).

  • But what are best practices for developing and running testthat unit tests for the custom functions in a drake workflow?

Any pointers to resources or examples would be greatly appreciated. Thanks!

1 Answers1

0

The best practices for unit tests do not change much when drake enters the picture. Here are the main considerations.

  1. If you are using drake, you are probably dealing with annoyingly long runtimes in your full pipeline. So one challenge is to construct tests that do not take forever. I recommend invoking your functions on a small dataset, a small number of iterations, or whatever will get the test done in a reasonable amount of time. You can run a lot of basic checks that way. To more thoroughly validate the answers that come from your functions, you can run an additional set of checks on the results of the drake pipeline.
  2. If you are using testthat, you probably have your functions arranged in a package-like structure, or even a fully-fledged package, and you may even be loading your functions with devtools::load_all() or library(yourPackage). If you load your functions this way instead of individually sourcing your function scripts, be sure to call expose_imports() before make() so drake can analyze the functions for dependencies.
landau
  • 5,636
  • 1
  • 22
  • 50
  • Thanks for your quick reply, Will! Reading between the lines, it seems you're suggesting that a repository that runs a drake workflow can also be an R package. Am I interpreting you correctly? If so, are there any resources for package/drake integration? (I'm not looking for info on R packages, as I have authored a few of them. Rather, info on having a "drake repository" also be a package.) Thanks again for the excellent drake package! – Matthew Kuperus Heun Apr 16 '20 at 13:33
  • 1
    I see the `drakepkg` package at https://github.com/tiernanmartin/drakepkg. Perhaps that is a good place to start. – Matthew Kuperus Heun Apr 16 '20 at 13:43
  • Yup, I you're on the right track with `drakepkg`. There's also a brief mention of the major general best practices at https://books.ropensci.org/drake/projects.html#workflows-as-r-packages, but it's not much. – landau Apr 16 '20 at 22:59
  • There are more examples in the wild, and I will come back and update this thread if I can find them. My own are locked down and company confidential. – landau Apr 16 '20 at 22:59
  • Thanks again, Will! I think my next step is to convert my existing repository that uses drake to a package structure. I'll report here on any experiences/gotchas that aren't available elsewhere. – Matthew Kuperus Heun Apr 17 '20 at 12:54