Forum Discussion

ZkElga's avatar
ZkElga
New Contributor
11 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.

Example: my project is configured to re-run on failure 4 times

First time: fail

Second time: fail

Third time: pass

In my test scripts, I need to know WHEN I am on the "First time", "Second time" and "Third time". Is anyone familiar with this? Is there any property or event which contains this piece of information?

Thanks.

  • ZkElga's avatar
    ZkElga
    11 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
    11 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. 

    • rraghvani's avatar
      rraghvani
      Champion Level 3
      11 months ago

      We are not criticising your work, we are just speaking from past experience, and based on the information you had provided.

      See @tristaanogre response from another post, which sums it up.

      Note, try...catch statement is used to capture exceptions and gracefully show an error message to which the user can respond, as opposed to having the application crashing and exiting.

      • ZkElga's avatar
        ZkElga
        New Contributor
        11 months ago

        try-catch can be used in many forms, maybe you just don't know how, I'm telling you from past experience

    • AlexKaras's avatar
      AlexKaras
      Champion Level 3
      11 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...)

       

  • AlexKaras's avatar
    AlexKaras
    Champion Level 3
    11 months ago

    Hi,

     

    Not sure such functionality exists out of the box...

    As a kind of workaround, you may consider dynamic creation of temporary project variable (one variable per retried test, for example). Those variables will not be stored persistently, so their creation during runtime will not make a mess with your source control system. Then, at the beginning of test execution, such variable can be used as a counter to make it possible to know retry number.

    (Though, they say, that if the test is unstable, one must either improve existing test code or this might mean a problem in the tested application.)

     

  • praveenskg's avatar
    praveenskg
    Contributor
    11 months ago

    can you tell how are you rerunning the failed scripts alone, i am working on implementing similar behavior but not sure where to start.  

    • ZkElga's avatar
      ZkElga
      New Contributor
      11 months ago

      https://support.smartbear.com/testcomplete/docs/testing-with/running/control-test-flow/stop-and-rerun.html