Forum Discussion
Ryan_Moran
12 years agoValued 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.