Closes #446: Adding lifecycle_verbosity to tests of deprecated functions

[ddsjoberg]

Deprecated functions, by design, throw warnings about those deprecations. Adding withr::local_options(lifecycle_verbosity = "quiet") inside the unit testing chunks for the tests we've written for these functions will quiet the lifecycle warnings.

---

Thank you for your Pull Request! We have developed this task checklist from the Development Process Guide to help with the final steps of the process. Completing the below tasks helps to ensure our reviewers can maximize their time on your code as well as making sure the admiral codebase remains robust and consistent.

Please check off each taskbox as an acknowledgment that you completed the task or check off that it is not relevant to your Pull Request. This checklist is part of the Github Action workflows and the Pull Request will not be merged into the main branch until you have checked off each task.

• Place Closes Add lifecycle option lifecycle_verbosity = 'quiet' to tests of deprecated functions #446 into the beginning of your Pull Request Title (Use Edit button in top-right if you need to update)
• Code is formatted according to the tidyverse style guide. Run styler::style_file() to style R and Rmd files
• Updated relevant unit tests or have written new unit tests, which should consider realistic data scenarios and edge cases, e.g. empty datasets, errors, boundary cases etc. - See Unit Test Guide
• If you removed/replaced any function and/or function parameters, did you fully follow the deprecation guidance?
• Update to all relevant roxygen headers and examples, including keywords and families. Refer to the categorization of functions to tag appropriate keyword/family.
• Run devtools::document() so all .Rd files in the man folder and the NAMESPACE file in the project root are updated appropriately
• Address any updates needed for vignettes and/or templates
• Update NEWS.md under the header # admiral (development version) if the changes pertain to a user-facing function (i.e. it has an @export tag) or documentation aimed at users (rather than developers)
• Build admiral site pkgdown::build_site() and check that all affected examples are displayed correctly and that all new functions occur on the "Reference" page.
• Address or fix all lintr warnings and errors - lintr::lint_package()
• Run R CMD check locally and address all errors and warnings - devtools::check()
• Link the issue in the Development Section on the right hand side.
• Address all merge conflicts and resolve appropriately
• Pat yourself on the back for a job well done! Much love to your accomplishment!

[github-actions]

Package	Line Rate	Health
admiraldev	95%	✔
Summary	95% (1099 / 1153)	✔

[bms63]

Should we also have this practice in admiral?

[bundfussr]

Should we also have this practice in admiral?

If we want to have it, we should update the "Deprecation" section in the Programming Strategy.

[bms63]

Should we also have this practice in admiral?

If we want to have it, we should update the "Deprecation" section in the Programming Strategy.

okay there is also this use of deprecate_soft that is nice as well. I will make an issue

[ddsjoberg]

Should we also have this practice in admiral?

If we want to have it, we should update the "Deprecation" section in the Programming Strategy.

@bms63 @bundfussr I think either this solution or removing tests for deprecated functions work for us. we just dont want to gunk up the testing output with warnings about deprecated functions that are entirely expected

[bundfussr]

Should we also have this practice in admiral?

If we want to have it, we should update the "Deprecation" section in the Programming Strategy.

@bms63 @bundfussr I think either this solution or removing tests for deprecated functions work for us. we just dont want to gunk up the testing output with warnings about deprecated functions that are entirely expected

I would not remove the tests for deprecated functions because we should ensure that they still work as expected. Currently we use suppress_warning() to suppress the deprecation warnings. I think it doesn't matter whether we use suppress_warning() or withr::local_options(lifecycle_verbosity = "quiet").

[bms63]

Should we also have this practice in admiral?

If we want to have it, we should update the "Deprecation" section in the Programming Strategy.

@bms63 @bundfussr I think either this solution or removing tests for deprecated functions work for us. we just dont want to gunk up the testing output with warnings about deprecated functions that are entirely expected

I would not remove the tests for deprecated functions because we should ensure that they still work as expected. Currently we use suppress_warning() to suppress the deprecation warnings. I think it doesn't matter whether we use suppress_warning() or withr::local_options(lifecycle_verbosity = "quiet").

Not sure of all the inner workings, but suppress_warnings() is an admiral custom function that puts the kibosh on any warnings wherease the lifecycle one is just specific to the lifecycle warnings?? If so, I sort of lean towards using the lifecycle one going forward and saving the suppress_warning() for the big guns.