Sign in to follow this  
Followers 0
wickerman

Test Wide Timeouts

6 posts in this topic

Hi,

I have a script that is calling many subscripts, i.e.,

include "start_env.au3"

#include "004.au3"

#include "005.au3"

#include "006.au3"

...

#include "097.au3"

#include "098.au3"

#include "100.au3"

include "close_env.au3"

OutputResults()

Now, rather annoyingly, I am finding many times that certain scripts are not completing due to new versions of the AUT. i.e., buttons being repositioned or new defects being found, meaning that the scripts are waiting on responses that can never happen and so my results handler is never called. I could put timeouts on every possible gui function, but that will be very tedious and so I wonder if it is possible in some way to install a script level timeout, something like this;

include "start_env.au3"

RunScript(004.au3, 30)

RunScript(005.au3, 60)

RunScript(006.au3, 20)

...

RunScript(097.au3, 10)

RunScript(098.au3, 30)

RunScript(099.au3, 50)

include "close_env.au3"

OutputResults()

Where

Func RunScript($script, $timeout)

; Set 30 second timeout and define callback function "Abort"

StartTimer($timerID, $timeout, "Abort")

#include $script

KillTimer($timerID)

EndFunc

Func Abort

; Exit or do something interesting

Exit

EndFunc

Or even better, carry on processing through the remainder of the test suite. Apologies if there is already a solution but I have searched the board and can only find tips on gui timeouts. What I need is a test wide timeout to catch all types.

Share this post


Link to post
Share on other sites



Fix your scripts so they work correctly under the current version, or only run them under whatever legacy version they used to run correctly under.

Your use of #include as though it was equivalent to Execute() is confusing and bad practice also. An #include file should only contain declarations. Period. It should declare functions and any required Global variables. Adding the #include line to a script just makes the functions available, it doesn't run them. It's possible to force it to work the way you have it, but that's very bad practice and sloppy design that is bound to cause more problems in the future.

:)


Valuater's AutoIt 1-2-3, Class... Is now in Session!For those who want somebody to write the script for them: RentACoder"Any technology distinguishable from magic is insufficiently advanced." -- Geek's corollary to Clarke's law

Share this post


Link to post
Share on other sites

Fix your scripts so they work correctly under the current version, or only run them under whatever legacy version they used to run correctly under.

Your use of #include as though it was equivalent to Execute() is confusing and bad practice also. An #include file should only contain declarations. Period. It should declare functions and any required Global variables. Adding the #include line to a script just makes the functions available, it doesn't run them. It's possible to force it to work the way you have it, but that's very bad practice and sloppy design that is bound to cause more problems in the future.

:)

PsaltyDS, thanks for the advice but I am not sure I follow you or agree with some of your points !!

My question was regarding the ability to set up a timeout on a chunk of code as opposed to a particular gui function call. The Execute() function does not allow the specification of timeouts and so I don't see what benefits that provides. I am pretty to AutoIT though and would be very interested, so please can you provide some code so I can see what you mean. I also do not understand your reasoning behind your suggestion that it is "very bad practice and sloppy design" to use #include scripts in the way I have shown. Each include script is standalone, abstracted, and performs the honourable gui calls with no dependency on other scripts. It is easy to add/remove scripts or to run an overnight endurance test or run single confirmation tests of certain scripts by passing in parameters to the main controlling script if I want to. For me, it is quite the opposite, very well designed. Ordinarilly I would agree that #include files should only house defines, but, the design of AutoIT promotes this usage so I do not see a problem using #includes to make life easier. Even the example shown in the AutoIt help page on using #include shows that #include files are used to execute code.

Also I don't think it a wise idea to have a set of scripts that work for each version of the AUT. This for me is brushing the problem under the carpet or chasing your tail. If I receive a new app to test next week, and the developer has added a bug in the code that means a window doesn't show when it should. Then, why do I need to spend time modifying my test suite for this new version. With 120 tests to run, if script 107 falls over then why should I have to take the pain to recode my scripts, re-version them and store them accordingly - and start again from the top. The fact that I get a timeout means that I have found a problem, so record the error, report a defect and move on.

Now, since posting the problem, I have come up with a workaround that does now exit the subscript with a timeout, and means the master controlling script continues processing of the entire suite, but it is a little crude and it would have been nicer if there were a neater solution already available in the language.

If anyone wants the solution, I will happily describe it - but it is specific to the model I am using above.

Share this post


Link to post
Share on other sites

PsaltyDS, thanks for the advice but I am not sure I follow you or agree with some of your points !!

My question was regarding the ability to set up a timeout on a chunk of code as opposed to a particular gui function call. The Execute() function does not allow the specification of timeouts and so I don't see what benefits that provides. I am pretty to AutoIT though and would be very interested, so please can you provide some code so I can see what you mean. I also do not understand your reasoning behind your suggestion that it is "very bad practice and sloppy design" to use #include scripts in the way I have shown. Each include script is standalone, abstracted, and performs the honourable gui calls with no dependency on other scripts. It is easy to add/remove scripts or to run an overnight endurance test or run single confirmation tests of certain scripts by passing in parameters to the main controlling script if I want to. For me, it is quite the opposite, very well designed. Ordinarilly I would agree that #include files should only house defines, but, the design of AutoIT promotes this usage so I do not see a problem using #includes to make life easier. Even the example shown in the AutoIt help page on using #include shows that #include files are used to execute code.

Also I don't think it a wise idea to have a set of scripts that work for each version of the AUT. This for me is brushing the problem under the carpet or chasing your tail. If I receive a new app to test next week, and the developer has added a bug in the code that means a window doesn't show when it should. Then, why do I need to spend time modifying my test suite for this new version. With 120 tests to run, if script 107 falls over then why should I have to take the pain to recode my scripts, re-version them and store them accordingly - and start again from the top. The fact that I get a timeout means that I have found a problem, so record the error, report a defect and move on.

Now, since posting the problem, I have come up with a workaround that does now exit the subscript with a timeout, and means the master controlling script continues processing of the entire suite, but it is a little crude and it would have been nicer if there were a neater solution already available in the language.

If anyone wants the solution, I will happily describe it - but it is specific to the model I am using above.

AutoIt is strictly single-threaded. To get what you seem to be describing, I would code each test item as a stand-alone, compiled script (.exe). The master script would run each required test via Run() and perform required timing/monitoring/logging from its own process while the test ran in another. Where appropriate, more than one test can be running at the same time.

By putting the un-compiled #include files inside the master script, they must always be compatible with the current version of AutoIt running the master. If the tests are compiled then it only matters that they work with the version they were compiled in. Only if you change one of the test scripts and re-compile it will you have to worry about it being compatible with the current version. Required dynamic parameters, like IPs or computer names, should be passed in the command line or a config file (i.e. ini or xml).

This, in my opinion, would be easier to maintain, more flexible, make easier reuse of existing scripts, and make it easier to add new ones. But of course it's only that, my opinion.

:)


Valuater's AutoIt 1-2-3, Class... Is now in Session!For those who want somebody to write the script for them: RentACoder"Any technology distinguishable from magic is insufficiently advanced." -- Geek's corollary to Clarke's law

Share this post


Link to post
Share on other sites

For my needs all scripts will only ever be compiled by the same AutoIT version, so I don't think that is an issue to factor in, but having the scripts run in seperate processes is really what I need. The main controlling script then acts as a type of process manager to handle the timeouts. This would allow me to override the Run() call to put any timeout I want in. That was how I envisaged this working originally except I originally wondered if this could be achieved using #includes instead.

It is straight forward to switch to compiled scripts, so I'll try to knock up a protoype and see if I can proceed further.

Share this post


Link to post
Share on other sites

how about "Run(@AutoItExe & ' /AutoIt3ExecuteScript ' & $sScriptFile)"?


[size="2"] "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian Kernighan[/size]

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0