Thank you for the example application demonstrating what you're trying to describe. I would like to point out a few things about your testing approach:
1) Clicking on buttons 1, 2 and three represent 3 separate features of the example application. Best practice says there should be a separate test for each feature, which means there should be one test for each button, not one test trying to click on all three buttons and testing all the features all at once.
2) The specific test step that clicks on button 2 really should not fail when you comment out the code inside of the event handler for button 2. The button was still present in the UI, it was clickable and the test automation did successfully click on it. There is no reason to fail that test step.
However the follow on test steps that try to interact with the popup window should fail because the popup window no longer opens. And they do fail as demonstrated in the attached test result file. The test correctly failed at the right point, the first test step that tried to interact with the popup window. If I had separated that test into three separate tests as I explained in item 1 above, I would have 2 passing tests and 1 failing test making it immediately crystal clear what functionality of my application is working and what is not simply by looking at which tests are passing and which are failing. I don't need to look at the test steps to determine where the broken functionality is.
3) You can take advantage of our "Continue on failure" feature to force the test to continue executing when a specific test step fails. This should only be used on steps where the remainder of the test would still be valid if that particular step fails (verification steps for example).
All the best,
the Telerik team
Do you want to have your say when we set our development plans?
Do you want to know when a feature you care about is added or when a bug fixed?
Telerik Public Issue Tracking
system and vote to affect the priority of the items