Greetings juce, paying customer here. Great library, use it heavily, love it in general.
I have a long-term feature request that I would like Jules to take under consideration. This is not a weekend project, but I think it would benefit both Roli and everyone in the entire Juce community very strongly.
I’d like to draw your attention to the JSON Wire Protocol at https://github.com/SeleniumHQ/selenium/wiki/JsonWireProtocol . This is the core protocol behind Appium and Selenium, and it is a de facto industry standard for cross-platform native app testing.
It strikes me that it would be very possible to implement a few classes in JUCE that perform introspection on the current visible windows and widgets in the current JUCE App, and then provide automation features to the world via JSON Wire Protocol, via an open port.
Enabling this, would open up a whole new universe of cross-platform automated testing and scripting features for all applications using JUCE. It would vastly simplify testing of all ROLI’s own products, and it would help everyone else outside ROLI’s walls as well.
Thanks very much for your consideration.
Yes, I think this would be a worthwhile addition to JUCE. However, as you say, it would be a significant chunk of work to get this up and running. Unless this thread explodes with other people requesting the same thing it will be difficult to justify putting it before other, more popular, features.
I’ll put this into our list of potential features, but for the moment at least it’s unlikely to go anywhere.
Yes, well, it isn’t called for because most of your customers can’t imagine its existence. A bit like your Live Build engine, which I don’t think a single one of your customers demanded, but now so many of them use.
Is there anyway in which this could be used to improve accessibility too? If so it seems to me that this would significantly increase the benefits of this proposal.
Appium uses the accessibility APIs in each OS to implement automation. For example, on Windows, Appium uses UIA, which provides accessibility services to modern Windows apps. In other words, implementing Selenium support would, by definition, implement accessibility support, at least on Windows and probably other platforms as well.
This is still a gating issue for smoke testing not only my Juce apps, but ALL juce apps. Implementing a WebDriver module for Juce would permit ALL Juce apps to have their GUIs automatically tested, as part of a build.
If I were to do this, I would start with CivetWeb and implement support for enough parts of the WebDriver API to permit all the Juce GUI objects to be queried and clicked on via the WebDriver protocol.
Once people understand that this is a very tractable way to test ALL Juce apps, on ALL platforms that Juce supports, then I think you will have a lot more demand for this feature.