Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/yonicd/reactor
unit testing for shiny reactivity
https://github.com/yonicd/reactor
r shiny testthat
Last synced: about 1 month ago
JSON representation
unit testing for shiny reactivity
- Host: GitHub
- URL: https://github.com/yonicd/reactor
- Owner: yonicd
- License: other
- Created: 2019-11-05T03:06:54.000Z (about 5 years ago)
- Default Branch: master
- Last Pushed: 2021-07-07T14:13:32.000Z (over 3 years ago)
- Last Synced: 2024-10-12T21:28:53.978Z (2 months ago)
- Topics: r, shiny, testthat
- Language: R
- Homepage: https://yonicd.github.io/reactor
- Size: 39.6 MB
- Stars: 60
- Watchers: 5
- Forks: 1
- Open Issues: 1
-
Metadata Files:
- Readme: README.Rmd
- License: LICENSE
Awesome Lists containing this project
- awesome-shiny-extensions - reactor - Unit testing for Shiny reactivity. (Developer Tools / Testing)
- jimsghstars - yonicd/reactor - unit testing for shiny reactivity (R)
README
---
output: github_document
---
```{r, include = FALSE}
knitr::opts_chunk$set(
collapse = TRUE,
comment = "#>",
fig.path = "man/figures/README-",
out.width = "100%"
)
library(details)
```
# reactor 
[](https://www.tidyverse.org/lifecycle/#maturing)
[](https://github.com/yonicd/reactor/actions)
[](https://github.com/yonicd/reactor/actions)
[](https://github.com/yonicd/reactor/actions)
[](https://tinyurl.com/yd2odf5g)
When developing Shiny apps there is a lot of reactivity problems that can arise when one `reactive` or `observe` element triggers other elements. In some cases these can create cascading reactivity (the horror). The goal of `reactor` is to diagnose these reactivity problems and then plan unit tests to avert them during development to make development less painful.
## Installation
And the development version from [GitHub](https://github.com/) with:
``` r
# install.packages("remotes")
remotes::install_github("yonicd/reactor")
```
## Usage
Reactor is a pipeline driven api where the user does not need to learn RSelenium in order to be able to drive their applications
### Initializing Reactor
Start by creating a reactor class object
```{r}
library(reactor)
obj <- init_reactor()
obj
```
### Populating Specifications
You can see it is expecting to be populated by two objects
- __application__: Specifications for the background process that will host the application
- __driver__: Specifications for the webdriver that will interact with the application in the background process
Reactor comes with functions to help you create these specifications
- __application__:
- `set_runapp_args()` : Assumes that the application is located in a path on the machine and uses `shiny::runApp` as the function to launch the application
- `set_golem_args()`: Assumes that the application is a [golem](https://github.com/ThinkR-open/golem) package and uses the `golem` logic to launch the application.
- __driver__:
- `set_chrome_driver()`: Launches `RSelenium` with a chrome webdriver
- `set_firefox_driver()`: Launches `RSelenium` with a firefox (gecko) webdriver
```{r}
obj <- obj%>%
set_runapp_args(
appDir = system.file('examples/good_app.R',package = 'reactor')
)%>%
set_chrome_driver()
```
```{details, echo = FALSE,details.lang = 'yml',details.summary = 'reactor object'}
obj
```
If you want turn off headless mode you can update the object
```{r}
obj <- obj%>%
set_chrome_driver(
opts = chrome_options(headless = FALSE)
)
```
```{details, echo = FALSE, details.lang = 'yml',details.summary = 'reactor object'}
obj
```
### Starting Reactor
Once we have specifications in place we can start reactor using `start_reactor()`.
```{r,eval = FALSE}
obj%>%
start_reactor()
```
### Interacting with the application
Now that the app is running we can send to the webdriver to interact with the application
- `set_id_value()`:
- expects an input id and the new value
- returns back the reactor object
```{r,eval = FALSE}
obj%>%
set_id_value('n',500)
```
The user can use the following utility functions to interact and query with an application
Inject:
- Inputs
- `set_id_value()`: Sets a value for a shiny input object by id
- JavaScript
- `execute()`: Executes a JavaScript call
Query:
- Inputs
- `query_input_names()`: Returns names of the shiny input ids
- `query_input_id()`: Returns current values of a shiny input by id
- Outputs
- `query_output_names()`: Returns names of the shiny output ids
- `query_output_id()`: Returns current values of a shiny output by id
- JavaScript
- `query()`: Returns a value from JavaScript call
### Closing Reactor
To safely close reactor and all the child processes use `kill_app()`:
```{r,eval = FALSE}
obj%>%
kill_app()
```
### Pipeline Operations
Because each function is returning the reactor object it is simple to create reactor pipelines.
Reactor will wait for shiny to finish each action before proceeding to the next one.
```{r,eval = FALSE}
init_reactor()%>%
set_runapp_args(
appDir = system.file('examples/good_app.R',package = 'reactor')
)%>%
set_chrome_driver()%>%
start_reactor()%>%
set_id_value('n',500)%>%
set_id_value('n',300)%>%
kill_app()
```
### Testing Expectations
Finally reactor tests reactivity expectations in a `testthat` framework using the builtin `expect_reactivity()` function
```{r,eval = FALSE}
init_reactor()%>%
set_runapp_args(
appDir = system.file('examples/good_app.R',package = 'reactor')
)%>%
set_chrome_driver()%>%
start_reactor()%>%
set_id_value('n',500)%>%
expect_reactivity('hist',1)%>%
set_id_value('n',200)%>%
expect_reactivity('hist',2)%>%
kill_app()
```