[Resending as my message was bounced from bioc-devel the first time] A large subset of Shiny apps can be thought of as purely functional mappings from inputs to outputs, where the inputs are determined by the user poking around the UI. I have always liked the idea of having a feature in Shiny where you could provide it with a list of input values and it would simply return to you a list of output values (where the output values might not always be that nicely packaged, e.g. a plot might be returned as a list that contains a base64-encoded URI).
If we had such a function, it could be used for both reproducibility and testability. However, the very large caveat is that it wouldn't provide reproducibility for some classes of apps (for example, if you have actionButton/observer pairs to do side-effecty work, or have reactives that accumulate state as inputs change--like this one<http://glimmer.rstudio.com/yihui/11-beta-hat/>). This would really be for apps whose final output can be determined give only a snapshot of the final input state. Michael's approach (encapsulating interactions using objects that can be replayed later) would work for a larger class of apps, at the expense of greater complexity for both the Shiny framework itself and for users of these APIs. The output of my approach would look like this: Inputs ------ n: 20 x: 100 y: 30 Outputs ------- summary: " Min. 1st Qu. Median Mean 3rd Qu. Max. NA's 1.00 18.00 31.50 42.13 63.25 168.00 37 " plot: [data URI with base64 encoded PNG] Whereas I imagine Michael's output would look more like a "flight recorder" transcript. > On Wed, Jul 31, 2013 at 9:38 AM, Tim Triche, Jr. <tim.tri...@gmail.com>wrote: > >> Right this is what I meant with the captureOutput() snippet. Perhaps the >> whole reactive dispatch loop could be run to log instead of the clever >> force- directed graph of closures updating that Joe showed off after >> presenting Wednesday. >> >> No good deed goes unpunished, and this suggests that logging what is >> being dispatched is possible, especially for a group of smart fellers like >> the Rstudio guys >> >> --t >> >> On Jul 31, 2013, at 8:57 AM, Kasper Daniel Hansen < >> kasperdanielhan...@gmail.com> wrote: >> >> > 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 >> > > [[alternative HTML version deleted]] _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
