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

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).