Testing, or R projects vs R packages

I am looking at a way to test R projects that do not follow the package structure of not having subdirectories in R/. testthat only has test_dir, which does not discover test files recursively. All workarounds seem very cumbersome and error prone.

Please correct me if I'm wrong, but I see two opposing approaches to R programming:

  • A) A R project + renv
  • B) A R package (dependencies in DESCRIPTION)

renv and the DESCRIPTION file already seem to overlap. Since the sheer existence of renv seems to acknowledge that there are situations where an R package would be too much (not to say splitting it up and maintaining cross-dependencies just within the context of a single purpose of the project), what is the reason that testthat does not really support non-package R code? In my opinion this would lower the barrier for people to get into TDD by far/encourage good practices among R programmers. Recent packages like box (even supported by renv) support strong encapsulation as found in other languages, and I think this is desirable even on a small scope.

I acknowledge the use of R packages, but for more "personal" use I have never seen any proper example on how to split up and manage a middle-size project which would lead to a myriad of packages that are by themselves really small (say DB access, preprocessing, ...). Having all these in a classic R package structure forces you to come up with long file name conventions, and long function names like validate_db_input, validate_preprocessing_input, which seems pretty verbose and also not helpful to have all these helper functions in a common scope. R is pretty unconventional in this regard, and since there are already R Projects, I wonder why the rest of the food chain does not get so much attention.


This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.

If you have a query related to it or one of the replies, start a new topic and refer back with a link.