Built site for [email protected]: 1d0c151

Author: schloerke

articles/use-application-audit.html

@@ -142,21 +142,26 @@ dependencies. [renv](https://rstudio.github.io/renv/) uses the same
 mechanism that is used by shinyapps.io and RStudio Connect.
 
 [renv](https://rstudio.github.io/renv/) auto-generates these three files
-using is`renv::init()` and `renv::snapshot()`.
+using
+is[`renv::init()`](https://rstudio.github.io/renv/reference/init.html)
+and
+[`renv::snapshot()`](https://rstudio.github.io/renv/reference/snapshot.html).
 
 | File              | Usage                                                                                                |
 |:------------------|:-----------------------------------------------------------------------------------------------------|
 | `.Rprofile`       | Used to activate [renv](https://rstudio.github.io/renv/) for new R sessions launched in the project. |
 | `renv.lock`       | The lockfile, describing the state of your project’s library at some point in time.                  |
 | `renv/activate.R` | The activation script run by the project `.Rprofile`.                                                |
 
-To create `.Rprofile` and `renv/activate.R`, call `renv::init()` within
-your App project. To create / update `renv.lock`, call
-`renv::snapshot()`.
+To create `.Rprofile` and `renv/activate.R`, call
+[`renv::init()`](https://rstudio.github.io/renv/reference/init.html)
+within your App project. To create / update `renv.lock`, call
+[`renv::snapshot()`](https://rstudio.github.io/renv/reference/snapshot.html).
 
 **Whenever you update packages on your development machine, you should
-run `renv::snapshot()` command again to make sure the packages used on
-GitHub stay in sync.**
+run
+[`renv::snapshot()`](https://rstudio.github.io/renv/reference/snapshot.html)
+command again to make sure the packages used on GitHub stay in sync.**
 
 To learn more about [renv](https://rstudio.github.io/renv/), please see
 their [Introduction to

articles/use-ci.html

@@ -149,6 +149,48 @@ on your shiny application object directly. Unfortunately, the test file
 will not be able to be saved. Instead, the test commands can be copied
 into a test script manually.
 
+## Running Applications with a function
+
+Some packages, such as [golem](https://thinkr-open.github.io/golem/),
+provide a function that runs or returns a shiny application. In this
+case, you can create a wrapper function to perform two actions: load the
+package and return an app. For example, if your package is named `mypkg`
+and the function that runs the app is `run_test_app()`, you can create a
+wrapper function like this:
+
+``` r
+run_mypkg_app <- function() {
+  library(mypkg)
+  run_test_app()
+}
+
+app <- AppDriver$new(run_mypkg_app, name = "mypkg-app")
+```
+
+For shorthand, you can also use the package function directly:
+
+``` r
+app <- AppDriver$new(run_test_app, name = "mypkg-app")
+```
+
+When using a function to initialize the `AppDriver`,
+[shinytest2](https://rstudio.github.io/shinytest2/) will automatically
+call
+[`pkgload::load_all()`](https://pkgload.r-lib.org/reference/load_all.html)
+when you execute `library(<pkg>)` or `require(<pkg>)` to load your dev
+package, `<pkg>`, in the background R process. Similar to
+[mirai](https://mirai.r-lib.org), there is no carryover to the execution
+within the background R process. All packages may need to be
+[`library()`](https://rdrr.io/r/base/library.html)’ed again.
+
+[golem](https://thinkr-open.github.io/golem/) provides a template
+`run_app()` function. [golem](https://thinkr-open.github.io/golem/) app
+authors can use the shorthand:
+
+``` r
+app <- AppDriver$new(run_app)
+```
+
 ## Other setup steps
 
 There are a few steps that are needed for both types of tests.
@@ -164,24 +206,27 @@ to the `Suggests` section in your `DESCRIPTION` file.
         shinytest2
 
 When all of these items are in place, you can test your package using
-`devtools::install(); testthat::test_local()` or by running
-`R CMD check` on your package. If you are using the RStudio IDE, you can
-also run Build -\> Test Package or Build -\> Check Package.
+[`testthat::test_local()`](https://testthat.r-lib.org/reference/test_package.html)
+or by running `R CMD check` on your package. If you are using the
+RStudio IDE, you can also run Build -\> Test Package or Build -\> Check
+Package.
 
-[shinytest2](https://rstudio.github.io/shinytest2/) requires that your
-package to be *installed* when testing.
+[shinytest2](https://rstudio.github.io/shinytest2/) **no longer**
+requires that your package to be *installed* when testing. It will load
+from your local path.
 [`testthat::test_local()`](https://testthat.r-lib.org/reference/test_package.html)
 (and related wrappers) eventually call
 [`pkgload::load_all()`](https://pkgload.r-lib.org/reference/load_all.html)
-to temporarily source the local R package. You can use
-[`test_local()`](https://testthat.r-lib.org/reference/test_package.html)
-to test non-[shinytest2](https://rstudio.github.io/shinytest2/) tests,
-but you will need to install your R package to safely execute your
-[shinytest2](https://rstudio.github.io/shinytest2/) tests. If not
-installed, it will create a confusing situation where your
-[shinytest2](https://rstudio.github.io/shinytest2/) tests are running on
-a *different* version of your R package (whichever was last installed),
-than the rest of your tests (the current source).
+to temporarily source the local R package in the foreground for unit
+testing. [shinytest2](https://rstudio.github.io/shinytest2/) has made
+the stance that App authors **must** call `library(<pkg>)` or
+`require(<pkg>)` on their package within their App. This ensures that
+the package is loaded in the background R process that runs the Shiny
+application. When `library*()` is called,
+[shinytest2](https://rstudio.github.io/shinytest2/) will automatically
+execute
+[`pkgload::load_all()`](https://pkgload.r-lib.org/reference/load_all.html)
+to load the package’s source code.
 
 ## How should I test multiple applications?