Getting control of Assertion

[swap811]

I am preparing one utility for testing some of the application. I need some help in some part of it.
Suppose I have launched one debug build application. Then in between one assertion has come which was put by developer. So I have to do 2 tasks:
1) Get the content of that assertion
2) Click ignore or some how ignore the assertion.

After this initial application will resume.
I am not having the code with me. So modifying existing exe is out of question.

[VictorN]

... Then in between one assertion has come which was put by developer. So I have to do 2 tasks:
1) Get the content of that assertion
2) Click ignore or some how ignore the assertion.

If the assertion failed - then something is wrong in the code.
So you should not *ignore* but *retry* to step in the code to see what could be the reason of a problem.

[Lindley]

Assertions should only be used for cases which absolutely break the code and should never happen. They're strictly sanity checks.

If you have a case in which it actually makes sense to log an error but continue, then you should be using return codes or exceptions to indicate the error rather than assertions.

[Arjay]

Since you are testing the app, you need to execute tests in a testing framework that can handle these sorts of errors.

What I've done to solve this problem in the past is to create a test execution framework that not only fires off the test application (script, exe, etc), but also monitors the system for error conditions (like app error dialogs, crash dialogs, system dialogs, timeout exceeded, and so on). This monitoring occurs on a two second interval. If it runs into an error condition (like an assertion dialog), it captures the text off the dialog, writes to a log file, takes and screen capture and closes the application being tested.

I know some folks prefer to keep running the application after encountering a crash with the idea of finding more bugs, but I believe that this approach is of little value because any additional problems you may find are probably a result of the app being in some funky state - as such, any additional issues found are not usually reproable.

I go as far as auto-restarting the system (and continuing the automation run) after encountering catestrophic errors. That way, I can be continue testing from a known, good state.