I don’t know if this is possible, but we have an app that has tons of branding issues, where dialogs and error messages are showing the old name of our product that has now changed. These boxes are all over the place, many being called from the catch blocks in various windows. In order to test that everything is working as intended, I was hoping I could create some kind of external tool that could throw an exception within my program, and allow QA to use it.
I can’t really make changes to the actual code (especially code that forces exceptions), but I was thinking maybe I make a side program that just allocates all the memory for something silly then the next click on my real app would throw an out of memory exception. Does this seem plausible? Is there an easier way to achieve something like this?
Surely there’s a finite limit to the number of dialog boxes which include branding? Search the codebase for every place you launch a dialog and make the corrections.
You could automate the testing by setting up sikuli to capture screen-shots in all your expected failure modes and then search those screenshots (using sikuli’s search mechanism) for the branding you’re worried about.
Writing a RAM-fill application is fairly trivial if you’re certain it’s a memory allocation issue that will trigger all these dialogs. Just allocate blocks of ever-decreasing sizes until you run out of memory then use Sikuli to click the button and capture the result. You may well find that if memory allocation is the issue and you’re running that close to the wind that your testing fails. If you have serious memory leaks like that you should be fixing them not handing it over to your poor QA team!