Multithreading and error handling

Apologies for the obscure title!

I have been using Eggplant/sensetalk for a few weeks now and have a couple of questions…

I’ve previously been programming in Java and so I am used to making the majority of my programs concurrent/multi-threaded, is this possible in sensetalk? To put it into context I run a series of tests on VMs connecting to VMware workstation’s built in VNC server and it’d be nice to be able to run tests on two VMs at the same time.

Also because of the scope of my tests I have had to code in lots of try/catch blocks for error handling, the problem being these are in specific places and I find myself repeating code all over the place…is it possible to have a global error handling script that will catch all exceptions/errors?

Yes you can run multiple scripts against multiple SUT at the same time if you have multiple licenses. Each license can only run a single script execution at one time. We have specific execution licenses for this that run completely in background so that you could still create scripts while they are running on the same system.

You could have a look at omega13. it is there to intercept execution when an error occurs. You can find more information by typing “omega13” into the Ad-hoc Do box which is located at the bottum of the Run Window.

You could of course place your repeatable actions in a separate script and as part of the catch area just call this script that performs the same actions all the time

Thanks for your reply, the omega13 script looks interesting, is there any additional documentation on it? And I’m assuming by that description that I have to script my own attemptRecovery handler?

There really isn’t any more documentation. You do need to write your own attemptRecovery handler since the steps to recover will be specific to your testing environment. You need to make sure that if your attemptRecovery script actually does anything that might fix things on the SUT, that it returns “TRUE”. If you don’t set the return value, then the Omega13 script assumes that nothing was found that could be repaired and it will just let the main script fail.

The sorts of things that Omega13 were meant to deal with are events like the Windows Update window appearing or other random events that are not driven directly from the events in the application being tested. As such, it’s often an iterative process to create an attemptRecovery script that covers those scenarios. It’s worth noting that when a script fails, eggPlant captures a full resolution screenshot, and that you can capture images from that screenshot to use in your scripts. So if you get a failure because an unexpected and previously uncaptured dialog appeared on the screen, you can extract an image of that dialog from the error screenshot (using the Preview or Paint app, for example) and add a check for it into the AttemptRecovery script. Note that if you do this, you can save the captured image into the Images directory, but you will then need to select the image in the eggPlant Suite window and open the Info drawer and edit the search type (which will be Precise by default and should probably be Tolerant or Text as required).

Ah brilliant, thanks for your reply!

Apologies for the double post, but I’ve run into another issue!

Sometimes and I’m not quite sure why, in the middle of my testing, active windows that eggplant is interacting with will go out of focus (and thus eggplant fails to input clicks or data). Is there anyway to have a handler that checks for this constantly? Or would I have to define a check for this every time I do something?