Forum Discussion

ZkElga's avatar
ZkElga
New Contributor
12 months ago

Access current re-run iteration from script (javascript)

Hello, I have my project configured to re-run the test cases that failed, and now I need to find a way to know (via javascript) on which iteration of the "re-run" is the current test case running. E...
  • ZkElga's avatar
    ZkElga
    12 months ago

    Well I found the property I was looking for, it can be accessed by calling Project.TestItems.Current.Iteration, it will return the number of the re-run iteration for each test case.

    ----

    For those who are so shocked by the idea of re-running a test case, if it wasn't necessary to "re-run/re-try" anything, then we wouldn't have "try-catch" in programming languages, and certaintly TestComplete or any other tool wouldn't have such feature implemented. Sure, if your tests are 2 clicks and a string validation, then a re-run is not needed; but when you work with multiple applications and a temporary server downtime can bring one app down for 20 seconds and later work fine, then yes, it's better to have a re-run that will make my test pass the second time, than whining about a 20 seconds downtime on a lower environment; and I can give countless examples of the "re-run" being a useful tool which doesn't compromise the overall results of the QA process and actually makes it even a useful tool for further analysis of the applications' stability.

    I don't understand why people feel the need to criticise other's work without even knowing why we're doing what we're doing. 

ZkElga's avatar
ZkElga
New Contributor

Well I found the property I was looking for, it can be accessed by calling Project.TestItems.Current.Iteration, it will return the number of the re-run iteration for each test case.

----

For those who are so shocked by the idea of re-running a test case, if it wasn't necessary to "re-run/re-try" anything, then we wouldn't have "try-catch" in programming languages, and certaintly TestComplete or any other tool wouldn't have such feature implemented. Sure, if your tests are 2 clicks and a string validation, then a re-run is not needed; but when you work with multiple applications and a temporary server downtime can bring one app down for 20 seconds and later work fine, then yes, it's better to have a re-run that will make my test pass the second time, than whining about a 20 seconds downtime on a lower environment; and I can give countless examples of the "re-run" being a useful tool which doesn't compromise the overall results of the QA process and actually makes it even a useful tool for further analysis of the applications' stability.

I don't understand why people feel the need to criticise other's work without even knowing why we're doing what we're doing. 

AlexKaras's avatar
AlexKaras
Champion Level 3
12 months ago

Hi,

 

> Well I found the property I was looking for [...]

Oh, great to hear this and this is one more time reminder to me to not only rely on my memory, but also to spend some time from time to time to go through TestComplete's documentation.

> then we wouldn't have "try-catch" in programming languages

try-catch is absolutely different approach from retrying.

> I don't understand why people feel the need to criticise [...]

This was not an attempt to criticize but expression of people's personal understanding. Quite often this happens because people are not oracles and thus may understand some situation differently than its author. Especially when situation description lacks details and author does not say something like 'don't ask me why this is done like that'. Considering your further explanation of the situation and assuming that adequate logging that makes it crystal clear that the test failed because of environment instability and this environment instability is expected, then re-trying the test might be an acceptable approach.

On the contrary, re-trying approach is often used to try to get 'green' test result. And if test passes within several attempts then nobody cares to find the real reason of previous test failure(s). This is a risky approach and this was the main idea of our notes about re-trying approach.
(And note, that people first tried to answer your question and only then express their opinion, so personally I would hardly consider this a criticism...)