Suggested approaches
Exported values
It cannot be recommended enough to use shiny::exportTestValues()
to test your Shiny app’s reactive values.
If we make the assumption that package authors create consistent
render methods, then we can test the values provided to render methods
using shiny::exportTestValues(). Let’s look at an example
of a Shiny app that displays a plot of the first n rows of
data.
It is recommended to make your render methods contain minimal logic so that the value being rendered can also be exported.
library(shiny)
library(ggplot2)
ui <- fluidPage(
numericInput("n", "Number of rows", 10, 1, nrow(cars)),
plotOutput("plot")
)
server <- function(input, output) {
dt <- reactive({
head(cars, input$n)
})
plot_obj <- reactive({
ggplot(dt(), aes_string("speed", "dist")) + geom_point()
})
output$plot <- renderPlot({
plot_obj()
})
exportTestValues(
dt = dt(),
plot_obj = plot_obj()
)
}
plot_app <- shinyApp(ui = ui, server = server)
plot_app
Both dt and plot_obj have been
exported. This means that they are available when executing
AppDriver$get_values(), AppDriver$get_value(),
and AppDriver$expect_values().
app <- AppDriver$new(plot_app)
values <- app$get_values()
str(values) # Output has been truncated for printing
#> List of 3
#> $ input :List of 1
#> ..$ n: int 10
#> $ output:List of 1
#> ..$ plot:List of 5
#> .. ..$ src : chr "data:image/png;base64,iVBORw0"| __truncated__
#> .. ..$ width : int 962
#> .. ..$ height : int 400
#> .. ..$ alt : chr "Plot object"
#> .. ..$ coordmap:List of 2 | __truncated__
#> $ export:List of 2
#> ..$ dt :'data.frame': 10 obs. of 2 variables:
#> .. ..$ speed: num [1:10] 4 4 7 7 8 9 10 10 10 11
#> .. ..$ dist : num [1:10] 2 10 4 22 16 10 18 26 34 17
#> ..$ plot_obj:List of 9
#> .. ..$ data :'data.frame': 10 obs. of 2 variables:
#> .. .. ..$ speed: num [1:10] 4 4 7 7 8 9 10 10 10 11
#> .. .. ..$ dist : num [1:10] 2 10 4 22 16 10 18 26 34 17
#> .. ..$ layers :List of 1 | __truncated__
#> .. ..$ scales :Classes 'ScalesList', 'ggproto', 'gg' <ggproto object: Class | __truncated__
#> .. ..$ mapping :List of 2 | __truncated__
#> .. ..$ theme : list() | __truncated__
#> .. ..$ coordinates:Classes 'CoordCartesian', 'Coord', 'ggproto', 'gg' <ggproto | __truncated__
#> .. ..$ facet :Classes 'FacetNull', 'Facet', 'ggproto', 'gg' <ggproto object: Class | __truncated__
#> .. ..$ plot_env :<environment: 0x7fad13bd3d58>
#> .. ..$ labels :List of 2
#> .. .. ..$ x: chr "speed"
#> .. .. ..$ y: chr "dist"
#> .. ..- attr(*, "class")= chr [1:2] "gg" "ggplot"Plots are notoriously hard to test consistently over time and
different platforms. Similar to
AppDriver$expect_screenshot(), there are many ways outside
of your code that the plot can produce a change which would fail a
visual test. Some of these include:
- Default system font changes, as different operating systems have different fonts
- Default system font size changes
- R version changes
When possible, it is recommended to use {ggplot2} over
base::plot() as {ggplot2} is getting closer
and closer to cross platform compatible. {ggplot2} objects
can also be inspected and compared using {vdiffr} for cross
platform support.
Snapshots vs values
Snapshot testing makes the test writing minimal and quick. However, this comes with a logical risk.
Snapshots are wonderful at determining if a change has occurred. But for the first execution of the snapshot there is nothing to compare, so the first value is taken as truth even if it is not correct. This allows for the opportunity for invalid values to be saved as truth. Most of the time, it is OK to use snapshots from the beginning of your testing experience, but keeping track of each snapshot file can be tedious when testing multiple applications with multiple variants.
To remedy this possibility, app values can be tested against known
static values. For example, instead of testing the initial value of
dt() against a snapshot, we can test it against
head(cars, 10).
# Snapshot code
app$expect_values(export = "dt")
# Manual expectation code
expect_equal(
app$get_value(export = "dt"),
head(cars, 10)
)If you have the time to manually inspect the snapshot files
afterwards, using AppDriver snapshot code provides clean,
minimal code. If snapshot files are unwieldy, you can use
AppDriver to retrieve values to test against known
values.
Example
Let’s look at how we could write a {shinytest2} test to
make sure the plot is updated after updating our numeric
input n. Assuming the Shiny app code above is
saved in app.R, we can look at
tests/testthat/test-export.R below. To successfully run the
code below, be sure to have {vdiffr} installed.
Since we are not calling AppDriver$expect_screenshot()
or AppDriver$get_screenshot(), we do not need to use
AppDriver$new(variant=).
# File: ./tests/testthat/test-export.R
# App file: ./app.R
library(shinytest2)
test_that("`export`ed `plot_obj` is updated by `n`", {
skip_if_not_installed("vdiffr")
app <- AppDriver$new()
# Verify `dt()` uses first 10 lines of `cars`
n10 <- app$get_value(input = "n")
expect_equal(n10, 10)
# Verify `dt10()` data is first 10 lines of `cars`
dt10 <- app$get_value(export = "dt")
expect_equal(dt10, head(cars, n10))
# Verify `plot_obj()` data is `dt()`
plot_obj_10 <- app$get_value(export = "plot_obj")
expect_equal(plot_obj_10$data, dt10)
# Verify `plot_obj()` is consistent
vdiffr::expect_doppelganger("cars-points-10", plot_obj_10)
## Update `n` to 20
app$set_inputs(n = 20)
# Verify `n` was updated
n20 <- app$get_value(input = "n")
expect_equal(n20, 20)
# Verify `dt()` uses first 20 lines of `cars`
dt20 <- app$get_value(export = "dt")
expect_equal(dt20, head(cars, n20))
# Verify `plot_obj()` data is `dt()`
plot_obj_20 <- app$get_value(export = "plot_obj")
expect_equal(plot_obj_20$data, dt20)
vdiffr::expect_doppelganger("cars-points-20", plot_obj_20)
})The second half of the test performs similar expectations to the first half of the test. This code can be pulled into a helper function and be written as:
# File: tests/testthat/test-export.R
library(shinytest2)
test_that("`export`ed `plot_obj` is updated by `n`", {
skip_if_not_installed("vdiffr")
app <- AppDriver$new(variant = platform_variant())
expect_n_and_plot <- function(n) {
# Verify `n` input equals `n`
n_val <- app$get_value(input = "n")
expect_equal(n_val, n, expected.label = n)
# Verify `dt()` data is first `n` lines of `cars`
dt <- app$get_value(export = "dt")
expect_equal(dt, head(cars, n), expected.label = paste0("head(cars, ", n, ")"))
# Verify `plot_obj()` data is `dt()`
plot_obj <- app$get_value(export = "plot_obj")
expect_equal(plot_obj$data, dt, info = paste0("n = ", n))
# Verify `plot_obj()` is consistent
vdiffr::expect_doppelganger(paste0("cars-points-", n), plot_obj)
}
expect_n_and_plot(10)
# Update `n` to 20
app$set_inputs(n = 20)
expect_n_and_plot(20)
})It should be noted that {ggplot2} objects can not be
serialized to JSON and should be excluded from the
AppDriver$expect_values() snapshots.