Here is a project I tossed together to spotlight Doug’s previous post, with some extensions for exception handling and automatic email notification upon script failure.
Included is a master script dispatcher, which may take in some data of which we create, or from another program via SenseTalk’s sockets, or a flat file from an test system, or even a hand coded list of scripts to run and post results.
The Main.script leverages the try…catch exception handling structure of SenseTalk. Also used is a powerful concept called script introspection to find if a script has an ‘owner’ when reporting test failures. If there is no owner, a default owner is assigned and notified. Using the RunWithNewResults command will put each test script’s results in its suite’s Results folder. These results can later be sent to script owners via the SenseTalk’s sendmail() attachment property.
There is some nifty exception handling going on as well. RunWithNewResults by definition will toss an exception if a file/script is not available to run. We wrap the call into a try…catch structure just in case someone/thing deletes or removes a script. If the script is present, yet somehow explicitly or indirectly throws an exception and not handled by the script itself, the try…catch by default will not handle the exception. This is how EP’s RunWithNewResults command is supposed to work, allowing ‘the result’ propertly list to be inspected for status immediately upon return (from normal execution or if an exception happens). If the result’s status is not ‘success’, then an error occured and we proceed to throw another exception which will be handled by the very same exception handler which wrapped the RunWithNewResults command in the first place. A very flexible and useful use of try…catch showing off the flexibility of SenseTalk’s exception handling mechanism.
In summary, we parse/generate some data, which in turn is made into some property lists each representing a test case to be run. Each test case is executed with the RunWithNewResult allowing isolated log files to be generated for reporting when an exception occurs. SenseTalks flexible and power try…catch exception handling is used double duty to handle local and called exceptions.
Try downloading this example, open and read the ReadMe.txt file, drag in the helper script to the TestExample suite, and run the Main.script. You will see three test scripts run, without errors. Then you may want to try playing around with throwing exceptions (uncomment the line in Test1.script for example) and see what happens. Maybe you can fill out the values in the notify handler to send practice notifications to you and your test team members when exceptions are thrown.
Some pitfalls and thoughts about this suite and message dispatch approach. It doesn’t handle test script name collisions, so each test script must be named uniquely across all helper suites. This could be handled by large unique script names, or by the opening and closing of suites programmatically using Eggplant’s OpenSuite and CloseSuite commands. The manual dragging of helper suites to the Helper tab panel is not ideal, yet works in the most simple of cases. In more complex situations where many projects are needing testing and needing daily changes, you may want to write a suite dispatcher also and have instead this suite act as the core script running tool and notifier within the suite dispatcher. Also, if your test requirments have dependencies, you may want to add your own rule set controller to handle the execution of test scripts flow control. For instance branching or repeating a test when one or more test scripts fail. All these ideas are left for the reader to explore while shaping a solution to their QA/Testing needs.