How do I not leave a Database Table Checkpoint as a blocker if I have different values?
How do I not leave a Database Table Checkpoint as a blocker if I have different values?
Forum Discussion
I'm not sure I understand the question. What do you mean by "a blocker"? What desired behavior do you want versus what you're experiencing? Are there error messages?
More detail, please.
I believe the question is how to keep the test going even though the Database Table Checkpoint fails.
If that's the case...
...a checkpoint failure logs an error. So, if the test run is halting after the database checkpoint fails, that means that somewhere along the chain, you're configured to stop on error.First place to look is in Tools | Current Project Properties | Playback. If Stop On Error is checked there, uncheck it.
Next place is in your project suite. If you double click on the Project Suite node, you'll see the following.
If that check box is checked, even if the project itself has "Stop On Error" turned off, this will also halt a test run.
Finally, if you double click on your project node, you MAY see something like this.
If you don't see those two columns, right click on the panel and select "Field Chooser". You can then drag those columns onto the panel for yourself. If "Stop on Error" is set to either "Test Item" or "Project", then when an error is logged, the appropriate level (either Test Item or the whole project) will be stopped.
That's the easiest place to start on this. Without further information from the OP, really can't suggest anything further.
I'm interested in this topic too! We really like running with Stop on Error because if it goes any further it could disguise or mess up evidence of the problem.
So, does anyone know if it's possible and practical to set Options.Run.StopOnError to FALSE, execute a try/fail block, and then set Options.Run.StopOnError back to TRUE?
Stop on Error is read in at the start of the test run. Consider it as part of the "compile" process before execution. It's "read only" during the test run.
If you want to have more granular control over whether or not a test run stops upon an error condition, it would be best to build that into tests. STart with "Stop on Error" set to false and then build your own runner controls. There are various techniques that are useful for this. You can use the Runner.Halt method for one. You can also build in try/catch/finally exception logic into your test cases and test framework and then manually raise exceptions to trigger test run cessation. Depends upon your specific needs.
