Your right, i just forgot to remove that sentence.
I mean that code (your first version):
def yourTest():
while not listen():
step1()
step2()
step3()
other_steps()Code above will do the whole "step1/step2/step3" even if inside that already was 10000 errors.
Thanks for these examples :) it gave me alot of new ideas.
I just want to know one more thing, cause for this moment can't imagine how to do that:
Lets say that i have 3 tests that doing the same thing, diffrence is one parametr - because i dont want to make 3 diffrent .py files i decided to create a one with a loop like:
def RUNALL():
param= ['P','Np','Pm']
number=1
year=16
for p in param:
SprAddModify.SprAddModify(p,number,year)
If inside "SprAddModify" ill get an error but only for param "Np" i want my loop jump to param "Pm" and stop executing "SprAddModify" for param "Np" on first cached error
Actually if i use OnErrorEvent and inside that ill put Close and run app it will be like:
Test for param "P" success
Test for param "Np":
looking for window A
close/run app
looking for window B
close/run app
etc...
No clue how can i impose stop running the whole method SprAddModify if inside it you encountered any error.
What i want achive (if my test fail for param "Np"):
Test for param P finished with success
Test for param "Np" failed
Test for param "Pm" finished with success
I will be rlly glad for any help.
Kind of depends what you mean by passed or failed.
If your test catches that it has failed and logs something accordingly, then your code above should be fine.
But if the second one fails and causes the code to throw an error, then is that what you want to handle?
I've done some Python, but not within TestComplete. The way I did it before, where a main loop was handing off to various smaller functions was simply to wrap the function calls in the loop within a try/except.
So in your case, something along the lines of:
def RUNALL():
param= ['P','Np','Pm']
number=1
year=16
for p in param:
try:
SprAddModify.SprAddModify(p,number,year)
except:
>> Log some sort of bug/failure here <<
>> Maybe also do some sort of application state tidy up? <<
... should be the bare minimum required to keep it moving I would think?
