Series
Testing shiny apps
These posts focus on testing Shiny applications with testthat
, shiny
’s testServer()
function, and shinytest2
.
Title | Subtitle |
---|---|
Behavior Driven Unit Tests | Part 1 (series): testthat’s BDD testing functions |
Testing Non-Package Shiny Apps |
Part 2 (series): Using testthat with Shiny outside of a package
|
Testing Shiny modules |
Part 3 (series): module server functions and testServer()
|
Shiny system tests with shinytest2
|
Part 4 (series): writing efficient system tests |
Testing rhino apps
|
Part 5 (series): Testing with box modules
|
No matching items
Testing details
testthat
:testthat
is a popular unit testing framework that allows R package developers to create tests scripts for functions and logic systematically. In a shiny app-package, it’s used for testing the non-reactive components (i.e., utility functions). This includes functions for data processing, plots, modeling, and other code that’s part of the package. However, it is not designed to work with shiny’s reactive model.- Post: Unit testing shiny utility functions: This post covers unit testing a set of utility functions with testthat. You can also read the documentation from the package website, in R packages, and in Mastering Shiny. The app-package for this post is stored in this Github Repo.
- Post: Unit tests for (non-package) shiny apps: Your shiny app should be developed as a package, but this isn’t always the case. If you’d like to test your application’s code without converting it to a package, check out the second post (GitHub repo with the code).
- Post: Unit testing shiny utility functions: This post covers unit testing a set of utility functions with testthat. You can also read the documentation from the package website, in R packages, and in Mastering Shiny. The app-package for this post is stored in this Github Repo.
testServer()
:testServer()
comes from the shiny package and is designed to test theserver
-side logic of your app. These tests can be used to simulate user inputs and verify the corresponding outputs.testServer()
can also test the functionality of moduleserver
functions (reactivity, outputs, and any returned values) in isolation from their UI function counterparts. However,testServer()
doesn’t capture how UI elements are rendered or simulate key user interactions (i.e., execution paths) through the application.- Post: Testing shiny module server functions: If you’ve built your shiny application as a package and it contains modules, this post covers testing module server functions using the examples from the ‘Modules’ chapter of Mastering Shiny. The code and examples are in this GitHub repo
shinytest2()
:shinytest2
is designed to perform end-to-end testing of shiny apps. These tests can capture a shiny app’s current state (i.e., a snapshot) and compare it with a previously saved (or expected) states. Snapshots are useful for end-to-end testing because they can simulate key user interaction in a way that unit tests andtestServer()
can’t (i.e., the delay between input changes and rendering updated outputs, specific sequences of selections on action buttons, radio buttons, etc.).shinytest2
tests are resource-intensive, so it’s recommended to write these tests after writingtestthat
unit tests andtestServer()
tests.- Post: Testing shiny apps with
shinytest2
: This post picks up where the previous post left off with theshinytest2
package. The app-package used in the examples is stored in this GitHub repo.
- Post: Testing shiny apps with
In summary, use testthat
for unit testing utility/helper functions, then testServer()
for the server-side logic, and finish off with shinytest2
tests for end-to-end functionality of your shiny app. These tools complement each other to provide a comprehensive testing framework.