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 <winston@stdout.org> wrote:

> On Mon, Jul 29, 2013 at 4:46 PM, Dan Tenenbaum <dtenenba@fhcrc.org> wrote:
>
>> Hi Winston,
>>
>>
>>
>> On Mon, Jul 29, 2013 at 2:39 PM, Winston Chang <winston@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]]

