How to manage long-running integration tests in an R package?

Package development
, , ,
1

Hi Posit Community,

We're seeking advice on how to best manage long-running integration tests: specifically, regarding their storage location (within the same repository or a separate one for just long-running tests) and their execution frequency. Our R package includes integration tests (for statistical models) that cause devtools::test() to take approximately 21 minutes, slowing down local development and CI as we add more tests for new features. We currently store all tests under tests/testthat.

We're considering the following approaches and welcome your feedback on their pros/cons or any alternative solutions:

  1. Use naming conventions (e.g., test-unit-*.R, test-integration-*.R) and develop helper functions to allow developers to run specific test subsets locally.
  2. Skip these long-running integration tests during R CMD check.
  3. Create a separate GitHub Actions workflow for long-running integration tests, to be run less frequently.

Thanks!

2

R CMD check does more things than just running tests. First, I'd ensure the tests are actually what's taking the bulk of the time. How long does it take to run devtools::test()?

3

Thanks for raising this question. It took 21 minutes to run devtools::test() on my local machine. The 15 minutes I mentioned in the post came from the GitHub Actions log. I’ll update the post to clarify.