Valreport #8
Valreport #8
Conversation
Zhenglei-BCS
commented
Sep 12, 2024
Zhenglei-BCS
commented
- added tests
- added inst/valreports
| ## Test Approaches | ||
|
|
||
| Based on the outcome of the risk assessment, different testing approaches will be employed, and corresponding testing reports will be generated. | ||
|
|
||
| - **Low Risk Packages:** For packages categorized as low risk, unit tests are sufficient to verify that the package is installed correctly and functions as expected. | ||
|
|
||
| - **Medium Risk Packages:** For medium risk packages, examples or vignettes should be executed to verify the functionalities of the package. | ||
|
|
||
| - **High Risk Packages:** For high risk packages, separate system tests must be conducted to ensure comprehensive validation. |
There was a problem hiding this comment.
I'm a bit reluctant to try to make a risk decision in this report, since the interpretation of risk can vary for different use cases.
Instead, I think we may want to just focus on concrete qualities of packages. This will also help keep the scope a bit more minimalist.
There was a problem hiding this comment.
Maybe a function riskcat can be created to give the user flexibility to supply their own criteria or thresholds to determin risk category.
| file_lists <- list.files(paste0(path0,"/tests/testthat/")) | ||
| if("_snaps" %in% file_lists) {file_lists <- file_lists[file_lists!="_snaps"]} | ||
| testResultsRaw_list <- lapply(file_lists,function(x)testthat::test_file(paste0(path0,"/tests/testthat/",x), reporter = testthat::ListReporter)) |
There was a problem hiding this comment.
If we want to handle arbitrary R packages we won't be able to assume that the package uses testthat as its testing framework.
I'm also a bit nervous about re-implementing testthat::test_package with our own handlers. testthat has some pretty strong assumptions on file names that we might also need to consider here. (setup-*.R files, and arbitrary fixtures files for test data. I think only test-* files actually get tested).
There was a problem hiding this comment.
It is not intended to do that but to give an example of what can be included in a single package testing protocol and testing implementation. Assuming that tests has been run by the reference image, could we take the same strategy as what has been implemented in the reference image?
|
About testing: pass / fail or more granular one, the bundled packages or additional ones. |
