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.