This issue is for discussion of a strategy for testing Shiny apps during CI runs.
There are several pieces needed to do this successfully:
A system for installing and configuring all the components. #2120 provides part but probably not all of this. See also discussion in #2097.
Tests of non-interactive components.
Tests of interactive components, possibly using recorded actions in a headless browser, e.g. shinyTest. @ashiklom might have more ideas about this.
Context
At the moment, the Travis build does no testing of any Shiny apps. This means that in practice, any issue the author misses will remain undetected until our uncompensated-tester-in-chief @serbinsh finds them while trying to get some science done.
Long-term, much of the functionality currently living in Shiny app code will probably want to be migrated into other PEcAn packages, where standard package testing strategies apply. But in the short term we need some assurance that the existing code does what we want, and we'll want to check that it continues to do what we want as we refactor it to move code into other packages. So we need Shiny tests even if the Shiny-specific code is kept minimal!
Description
This issue is for discussion of a strategy for testing Shiny apps during CI runs.
There are several pieces needed to do this successfully:
Context
At the moment, the Travis build does no testing of any Shiny apps. This means that in practice, any issue the author misses will remain undetected until our uncompensated-tester-in-chief @serbinsh finds them while trying to get some science done.
Long-term, much of the functionality currently living in Shiny app code will probably want to be migrated into other PEcAn packages, where standard package testing strategies apply. But in the short term we need some assurance that the existing code does what we want, and we'll want to check that it continues to do what we want as we refactor it to move code into other packages. So we need Shiny tests even if the Shiny-specific code is kept minimal!