replace test template with standalone files

[Bai-Li-NOAA]

Add a standalone file for the {testthat} test template so other repositories can import the same template using usethis::use_standalone() without depending on entire {FIMS}. Other NOAA-FIMS repositories can import the FIMS template directly instead of manually copying files from the FIMS repository.

To implement the solution:

• Delete use-testthat-template.R and add standalone-use-testthat-template.R
• Move {testthat} template from inst/tempaltes to .get_testthat_template()
• Update test-use-test-template.R to match new template
• Convert gtest template into a standalone file
• Add documentation in the gtest template so we can append _xxx after HandlesEdgeCase or HandlesCorrectInput to provide additional detail. See comment Refactor gtest files to use_gtest_template() convention #1433 (comment).
• Add a test for fimsMath_logit. See comment Refactor gtest files to use_gtest_template() convention #1433 (comment).

[kellijohnson-NOAA]

@Bai-Li-NOAA do we want to keep these template files given that we can use AI to generate the structure of a test file based on the structure of other files? I guess this takes tokens if we do it this way but it also saves us from having to maintain a file? Personally, I am not using these templates and I just copy and paste what I need to ask copilot. What are your thoughts? Is anyone using these templates? @grantdadams are you interested in us keeping the templates as standalone files so you can use them outside of FIMS with RCEATTLE?

[Bai-Li-NOAA]

@kellijohnson-NOAA I think it would be beneficial to maintain one sets of template files in a dedicated repository (e.g., FIMS) and allow other repositories to import these templates. AI can generate the structure of a test file more effectively because these templates provide an established pattern to follow. For a new repository that does not yet have templates, I think it is challenging for AI to generate a consistent test structure from scratch unless we explicitly instruct it to follow an existing example from FIMS.

Another reason I would like to have standalone template files is that they can be imported into other packages within the NOAA-FIMS organization without creating dependencies on FIMS or requiring manual copying. For example, I manually copied test templates from FIMS into {ecosystemom}. Now the FIMS templates are updated, I would prefer not to manually copy them again. Instead, we could use a GHA to automatically synchronize updates from the standalone template repository to {ecosystemom}.

Out of scope for this discussion: I am also wondering whether stockplotr::theme_noaa() could be maintained as a standalone file so that we can import the function directly into FIMS without requiring FIMS users to import the entire stockplotr package, since this is the only function from stockplotr that we currently use in the FIMS codebase. One caveat is that I have not explored the use of standalone files enough to know whether there are any potential drawbacks or limitations to this approach.

[iantaylor-NOAA]

@kellijohnson-NOAA, do you find that the AI generated test follow the template structure pretty well? My one worry about doing away with the template would be increased inconsistency among the tests. However, an alternative to a template, what about a standard copilot prompt (e.g. expand on the following adapted from the instructions in https://github.com/NOAA-FIMS/FIMS/blob/main/inst/templates/testthat_template.R). Or maybe we don't even need that at all if we have enough tests that are adequately consistent such that the AI can just follow the patterns.

Please generate a testthat test script for XXX. Necessary tests include input and output (IO) correctness correctness, edge-case handling, and built-in errors and warnings. Every test should have a @description tag, which can only span one line, that will be used in the bookdown report of the results from {testthat}. This line can be more than 80 characters.

[iantaylor-NOAA]

Sorry, I replied before seeing the reply from @Bai-Li-NOAA.
Regarding stockplotr, having a stand-alone file seems reasonable, but in the future I would expect that 99% of FIMS users SHOULD install stockplotr whether required or not because I think being able to generated figures and tables is an essential part of the assessment enterprise and the fewer barriers in the way of doing so, the better.

[kellijohnson-NOAA]

I am fine with keeping them as long as they are useful. I use a mix of prompts to copilot, sometimes I give it the path the template file, sometimes I just say match the other structure in the other files. But, I think it is highly beneficial to have the templates for those that do not have copilot.

Second, we use stockplotr a lot more than just for the theme. It is used in the vignettes for plotting. So, no we do not want to use the theme of stockplotr as a standalone template.

[Bai-Li-NOAA]

Thanks both @iantaylor-NOAA and @kellijohnson-NOAA. I was thinking about the distinction between putting stockplotr in Suggests versus Imports. If we mainly use it for vignettes, then Suggests would make sense since it would not be a hard dependency for installing FIMS. However, if FIMS R functions depend on stockplotr functions, then it needs to be included in Imports so that stockplotr is installed along with FIMS, otherwise, developers and users will encounter installation errors or devtools::load_all() errors.

I agree that we will likely use {stockplotr} more and more. I just saw multiple functions from stockplotr being used in FIMS on main, so it makes sense to import the whole package. This has been addressed through PR #1628 by adding stockplotr to Imports and including it in Codespaces for developers.