I don't know how this actually works in practice. But conceptually, I think of moving a slider in an Shiny app as possibly executing some R code. It will be important for production quality code release that we are able to test that this code works in a easy and portable way. I realize we may not be able to simulate moving the slider without actually doing it, but some of us wants to test the underlying R code, which is especially important when you code up against packages in heavy development. Perhaps this is easily done by adhering to a certain coding style. If so, we are happy to get advice.
Best, Kasper On Wed, Jul 31, 2013 at 11:45 AM, Winston Chang <wins...@stdout.org> wrote: > On Mon, Jul 29, 2013 at 4:46 PM, Dan Tenenbaum <dtene...@fhcrc.org> wrote: > >> Hi Winston, >> >> >> >> On Mon, Jul 29, 2013 at 2:39 PM, Winston Chang <wins...@stdout.org> >> wrote: >> > Hi everyone - >> > >> > Great to hear from you all on your thoughts about Shiny. I've tried to >> > answer some of Dan's questions below... >> > >> > >> >>> >> >>> 1) Testing shiny apps >> >>> >> >>> Typically, bioconductor packages have man page examples, vignettes, >> >>> and (sometimes) unit tests, so when we build the packages every day on >> >>> our build system, the code in all of these is evaluated and we have >> >>> some idea of whether the package is working as it's supposed to. >> >>> >> >>> I'm not clear on how to do similar testing of a shiny application. >> >>> Since launching a shiny app takes away the R console (until the app is >> >>> closed), shiny apps should probably not be launched in example or test >> >>> code (unless interactive() is TRUE). >> >>> >> >>> Do the shiny folks (or anyone else) have thoughts on testing shiny >> apps? >> > >> > >> > With regard to testing, we have unit tests for various components, and >> we're >> > working on end-to-end tests using Selenium. >> > >> > We do have some unit tests in inst/tests/, but they are entirely on the >> R >> > side - they don't test interaction with the browser. We have some other >> > tests in inst/tests-js/, which exercise the client (Javascript) side, >> but >> > they don't test interaction with the server. >> > >> > Of course it's important to have tests for client-server communication. >> > We're also in the process of setting up some end-to-end tests using >> > Selenium, but that's just in the beginning stages right now. Hopefully >> in >> > the future we'll have more to say about these kinds of tests. >> > >> > >> >> My feeling (and I could be wrong) is that Bioconductor package >> developers will be more concerned with testing the basic logic of >> shiny apps, and that therefore testing only in R would be sufficient >> for the most part. For example, if you could simulate a slider in a >> unit test by just changing a reactive value, it would not be necessary >> to make sure it works in the deployed context (with browser and >> server). >> > > Unfortunately, the testing of logic in a Shiny app does require an active > connection from web browser, since the state of a Shiny app includes both > the server and client. In other words, you can't simulate a slider value > change without actually starting a web browser -- although it may be > possible to automate these tests using something like phantom.js, which is > a headless web browser that can be used for testing. As I mentioned, we're > working on setting up some tests like this. > > On a related note, someone on the Shiny-Discuss mailing list just posted > about a project he's working on which makes it possible to have R and > Selenium WebDriver commuicate: > https://github.com/johndharrison/RSelenium > > Best, > -Winston > [[alternative HTML version deleted]] _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
