Following a preliminary discussion initiated in a previous thread (see issue Projucer 4.3.1 problem with on-screen keyboard which is a regression of 4.3.0), regarding the methods used to ensure the non regression of the developed widgets/components, I open this thread to get more information…
So the point is the following : What is your recommended method to test Juce applications, knowing that the classical used tools in GUI Testing (Ranorex, Selenium, Squish, Silk Test, or also QTP, UFT…) don’t work.
We need your status and advice, specially because we really want to have a strict control of the stability of all our produced software. The level of stability/quality is an important criteria for our developments (in fact, for all the developments in general, not only ours )
Thanks in advance for your answers.
PS: When I was in Juce Summit 2015, I didn’t have the opportunity to address this point…
Well, now accessibility is here you could consider some of the more classical GUI testing tools. That being said I often think that kind of approach is very fragile!
To be honest I don’t have much experience with these but from what research I’ve done in the past it seemed to me this kind of GUI testing is very fragile and isn’t particularly great at detecting issues you really want to detect - certainly not for telling you what the problem really is. I think by keeping your view (the bit that draws) as thin as possible with little to no logic you can add tests into your application that catch the majority of issues with some manual QA and beta testing to supplement it. That’s just my opinion and others experiences might be different.
)