Forum Discussion

mzimmerman's avatar
mzimmerman
New Contributor
8 years ago

Setup and Tear down, as well as Try Catch questions.

Hello,

 

I am fairly new to TestComplete, so please bear with me.  I am using TestComplete to test a windows application.  I am more used to the NUnit side of things.  In NUnit, you can have setup and teardown functions that will run before any test as well as after any test, even if there is an failure in that test.  Does TestComplete have this kind of functionality?  If it does not, is there any easy work around to always be in a consistent state for each test?

 

Also, I am trying a try catch block using JavaScript in TestComplete.  Basically to try to close my app, and if it cannot, catch by writing to the log.  My problem is, if inside the try look, there is an error, the test just stops.  So, I am unsure why it just doesnt kick to the catch, and move on like nothing is wrong.  Is this expected, and if so, what is the point of try catches in TestComplete.

 

Thanks for all of your time. 

javascript
Setup
Teardown
TestComplete
try catch
  • mzimmerman's avatar
    mzimmerman
    New Contributor
    8 years ago

    You have all given me great info.  Thank you for your posts. 

  • AlexKaras's avatar
    AlexKaras
    Champion Level 3
    8 years ago

    mzimmerman:

     

    Hi,

     

    Yes, already mentioned OnTestStart and OnTestStop events can be used as Setup and TearDown analogues...

    However, my preference and recommendation is to have a dedicated setup routine and call it explicitly at the beginning of the test code.

    Several reasons why this is my preference:

    -- Code in event handlers cannot be conveniently and easily skipped which may be often needed while test code creating and debugging. Having complex and time consuming setup and teardown procedures you will constantly lose time when starting *any* routine for debugging in your test project. Quite often this is not needed because you already may have environment in the required state and you may want to start test code execution not from the test start but from some intermediate point that is much closer to the point where you want to debug;

    -- Absence of teardown code will left your test system in the state that it had when an error occurred. This may be handy for the further analysis because you might not need to repeat the same 20 minutes-long test just in order to put test system in the required state and you can put test system to the required state in the setup code;

    -- Use of teardown is one of the used approaches for the unit testing that usually verify if some *operation* can be done in certain well defined conditions. By definition, operation either can be executed or not and this is one of the reasons why all unit test tools are assertion-based and have setup and teardown handlers. TestComplete can work in a unit-testing emulation mode, but usually it is used for the functional testing which differs from the unit testing in that it verifies whether some *task* can be done or not. The task usually consists of several operations and it may be not critical for the task if some operation fail.

    (For example, if your application creates some publication, the task may consist from Create, Insert Text, Insert Picture, Print and Save operations. There is no reason to stop the test if, say, Insert Picture operation fails. Yes, this problem must definitely be reported, but if you stop then you'll not know if the publication still can be saved and printer while if you continue you will know this and be able to report and make relevant decisions.)

    And it is quite a common practice to have functional tests to reuse results of the previously executed ones and this may require the absence of the teardown code. For example, if some error occurs while publication is saved but the Save procedure does not crash (e.g. pictures are not saved, but everything else is saved fine), it may not be needed to delete such publication is the teardown code but reuse it in the test that iterates through all existing publications and tries to print them - obviously, good Print operation must not crash for problematic publication (though it may fail with the proper message to the user).

    • cunderw's avatar
      cunderw
      Community Hero
      8 years ago

      What I have found that works well is to check for desired test run state in the test start and test top events. A config file or environment variable with call APP_RUNSTATE for example, with either Development or Execution, which will only run the step / tear down operations if it set to execution. 

    • mzimmerman's avatar
      mzimmerman
      New Contributor
      8 years ago

      Thank you for your suggestion for event handlers.  Those are exactly what I was looking for.

       

      I do have a follow up question about try/catch errors.  I basically want to shut down my application before I try to open it.  So, what I planned on doing is in a try block, put in the function to shut down my application, and not really do much in catch.  Doing it this way, even with that option unchecked, this behavior will make it look like all my tests fail, when it only failed expectedly when it could not find my open application.  I just thought try catch blocks did not report a test had failed, unless you threw your own error in the catch block.  Is there a better way to check processes or something to verify if my application is running before trying to close it?  I just thought the try catch was a pretty easy way to do this, until it actually reported successful tests were failures.

       

      • cunderw's avatar
        cunderw
        Community Hero
        8 years ago

        So the try / catches will only catch code errors and exceptions, not Test Complete errors.

         

        Test complete is logging an error when you are getting when you try to close your application if it's not open because there is no object to send the terminate command too. It's not throwing an exception which is why the try / catch is not catching it.

         

        There are several ways to go about it (depends on if you're mapping, using finds, etc..). But, in general what you would want to do is check if you application is running and only force the shut down if it is.

         

        Some psuedo code:

         

        if(Aliases.application.Exists) {
  Aliases.application.Terminate()
} else {
  Log.Message("Application Not Running")
}