Open telegott opened 3 years ago
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.
@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!
Closely related: how to test module internals (i.e. non-exported functionality)? Originally asked in #221 by @aniaskrzydlo.
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 teststest-*.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 ofbox
I could see structures likeR/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
I haven't found a clean solution with
testthat
that would allow something like this in abox
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 oftestthat
.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 orpipenv
andrenv
, 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 thebox
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.