Forum Discussion

help's avatar
help
New Contributor
10 years ago

Resume running a project when it stopped on error

Is there a option to continue the running of a project from where it stopped due to an error.



Thanks,



6 Replies

  • chrisb's avatar
    chrisb
    Regular Contributor
    I implemented this in our project the following way:



    1. Switch off the stop on error setting in the project.

    2. Script the test so it calls runner.stop on a failure.

    3. Enable the OnStopTest event handler in Events.

    4. OnStopTest script does whatever clean up is required. Additionally in our project if its the final test in a run it does email notifications and some other stuff.



    Calling Runner.Stop on a test failure will tell the test engine to start the next test. There are of course many ways to architect your project to do what you want. But in general terms, yes you can continue a test run when a test fails on an error. With the exception of some system level errors such as Test Complete objecting to a syntax error for example.



    http://support.smartbear.com/viewarticle/55220/



    And follow Robert's advice of using the try/catch block. It's a 'lifesaver' for us too, especially for catching javascript runtime errors.  
  • TanyaYatskovska's avatar
    TanyaYatskovska
    SmartBear Alumni (Retired)

    Hi,


     


    Will it work for you if you just disable the Playback | Stop on error project option? In this case, TestComplete won't stop the test execution when an error occurs.


     

  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor
    As Tanya mentioned, once a project has stopped due to the error, it's stopped.  If you want to pick up where it left off, you could disable the test items or comment out the code/keyword steps leading up to that point and click Run again, but that's not EXACTLY what you want to do.



    What I've done in the past is build in error handling (try/catch and the like) to handle errors that occur during execution.  This is a life saver because, if done properly, even if an error happens, you can utilize the catch routine to "clean up" after the error and make a logical determination as to whether the error is critical (meaning stop the tests) or simply serious (meaning log and continue).
  • help's avatar
    help
    New Contributor
    Thanks for the answers. But in my test cases, each test case is really dependent on the output of the previous one.



    So I can't stop/handle the exceptions and move on to the next test case. Even if I do, its not going to help me any way.



    The option I am looking for is similar to the following:

       

         If Error Found, then:

                     1) Pause the execution

                     2) Report Error

                     3) Correct the error Manually

                     4) Resume the test.



    Does TestComplete has any option similar to this?
  • chrisb's avatar
    chrisb
    Regular Contributor
    I dont believe there is any switch you can enable for this scenario in a test run. You could script it for sure by using event handlers.



    How about using the event handlers, in the example below you could use OnStopTest and OnStartTest to do what you are looking for...



    1. Call Runner.Stop when the test fails.

    2. OnStopTest saves the name of current test that is running (perhaps in project or project suite variable?). Get the current test name using the test items object.

    3. OnStart test resumes the test run from the test name that was saved in step 2.



  • Ryan_Moran's avatar
    Ryan_Moran
    Valued Contributor
    If you organize your tests into various segments/units you can accomplish this. In fact I do exactly that with my data-driven scripts and I use what I call break points. These are small sections of my scripts that can run independently from each other. At each segment if a critical error occurs I catch it with on_error events (or other methods previously suggested here) , restart the application(s), then resume the remaining segments of the test. How you design that type of test can be entirely unique and up to you, to fit your needs. Ideally you don't want to manually address any issues until all issues are revealed. I say this because as your script collection grows and you have several hours worth of tests to run you likely will not want to stop for every little error that occurs. Going further into detail you can also assign your own error handling using try..catch methods, post your own errors, and specify a priority to those errors to determine which are game-breaking and which are acceptable for the remaining tests to continue running. You'll also find the Log.Error method supports priority levels which work well with this methodology.