Many of the functions in this package are fragile to edge cases (because input data can be "corrupt" in many ways), yet lend themselves well to (automated) unit testing.
I think this is something we should aim to implement in all BTO packages eventually, but I think this package would be a good place to start given its highly modularized design, and (mostly) easy to assess function correctness.
I've implemented some initial unit tests in my fork (https://github.com/pboesu/BTOTools/commit/fbe439d0ba5b2769a9e0681c075016e51bb6e3a7 ; in response to #24), as well as automated R CMD Build checking via github actions (https://github.com/pboesu/BTOTools/commit/1cc4069289ac5ad08782587fa584d709caca4f25). The set up is pretty straightforward via the usethis package. Happy to put this in place for the main repositry but wanted to double check I am not interfering with other "offline" testing workflows you might be using.
Many of the functions in this package are fragile to edge cases (because input data can be "corrupt" in many ways), yet lend themselves well to (automated) unit testing.
I think this is something we should aim to implement in all BTO packages eventually, but I think this package would be a good place to start given its highly modularized design, and (mostly) easy to assess function correctness.
I've implemented some initial unit tests in my fork (https://github.com/pboesu/BTOTools/commit/fbe439d0ba5b2769a9e0681c075016e51bb6e3a7 ; in response to #24), as well as automated R CMD Build checking via github actions (https://github.com/pboesu/BTOTools/commit/1cc4069289ac5ad08782587fa584d709caca4f25). The set up is pretty straightforward via the usethis package. Happy to put this in place for the main repositry but wanted to double check I am not interfering with other "offline" testing workflows you might be using.