Mechanism for testing box-package based project structures

[telegott]

Since the box package marks a partial departure from traditional R code structures, I would find it useful to also support testing these non-traditional R code structures.

Specifically, testthat::test_dir(<the-dir>) only tests test-*.R files in <the-dir>/ but not in <the-dir>/<the-sub-dir>/.

This make sense in a R package structure which does not allow subfolders in R/, but making use of box I could see structures like R/database, R/utils, R/preprocesssing and so on.

The particular use case here would be to have an easy setup for continuous integration with Github Actions, such as

- name: Run tests
  run: |
    Rscript tests/run_tests.R

I haven't found a clean solution with testthat that would allow something like this in a box setup, like running multiple tests, collecting the status in a single reporter and putting out a single exit code without drilling into the internal code of testthat.

I know that this question probably belongs into the testthat-repo, but there wasn't much support being signaled for similar questions, and I wondered if you encountered this task already.

I still think that, despite R being very friendly for R-Users, the gap to use learn software engineering practices like modularity, unit tests and linting is pretty large, and while there are many similarities for using box and python imports or pipenv and renv, the R package structure does not have a direct analogy I can think of anywhere else, and for a lot of users it's not clear how to break up functionality into packages, then how to manage all these packages, and there are very few guides out there for realistic applications. So most R users just don't seem to bother, don't write packages and don't write tests, because it seems too daunting. I think combining the box package with a CI setup for Github Actions which is now easier than ever might help to mitigate the gap between using R and moving towards more solid code.

[klmr]

Just a quick note that I’ve seen this question but I don’t have an answer ready.

Just briefly: For now I would prefer not stuffing the package with too many features, and to concentrate on the core functionality (maintainer time is limited, and other features, such as versioning, have high priority). — But there are good arguments for coupling unit testing closely with module management (other modern ecosystems do similar things). At least in the long run.

[telegott]

@klmr thanks for the answer, the priorities are absolutely understandable. Thanks again for this package, one of the most useful recent additions to the R ecosystem!

[klmr]

Closely related: how to test module internals (i.e. non-exported functionality)? Originally asked in #221 by @aniaskrzydlo.