We have to run a number of tests in a suite unattended with no manual help and the problem is when the application crashes, the test suite is stopped and should be handled.
Is there a way to not stop on this crash and continue with the test run suite?
I have tried to put these kind of errors in try catch blocks and handle them this way.
The test suite is configured to continue with the next test.
I used also Runner.Stop(true) that should stop the current test and start the next test in the suite. Is there a way to treat the Error Could not obtain object in some way or another without failing all the other tests in the suite?
Have you configured the project stop on error properties?
I do not need to Stop on Error. I want the test run to continue with the next test if an error occurred in a previous test. At the moment I have treated such errors with try-catch blocks.
The problem is that sometimes I have an alert displayed, which I need to handle, but when this alert is not visible, the test will fail with Cannot obtain the object message. Do you know how this error cand be handled?
If configure the properties correclty your suite will not stop is what I was meaning.
Handling an alert you do not expect is something else. You could try calling the SetFocus method on the object. But without more information about the alert and your existing code that's just a shot in the dark.
I managed to handle the pop up, but that pop up can occur random, and there is that Cannot obtain error which I am not sure it can be handled in the test scenario, without failing the entire suite.
This may be the direction you need to go.
Can you please give me more details on how can I do this ?
"throughout your test cases code to detect active forms and such. "
Here is an example but if the operator button is not present than it fails at the moment
var operatorButton = KDIUtils.findElement("WRITELOCKVIEW.OPERATORBUTTON");
if (operatorButton.VisibleOnScreen == true)
Log.Error("Expected to be logged in As Operator. Main Write Lock view is displayed instead.");
In my case, it was code that replaced your line for finding the Operatorbutton. We called it "ActivateForm". Basically, we would pass into it the form name of the expected "next" form that we were expecting to see. We then executed a bunch of code that was unique to our situation.
Generally, you're going to want a common method that you're going to be able to call anywhere that, upon going to a form or attempting to get a component or whatever the situation may be, you call that code before you attempt any actions against the component to do a "sanity" check to make sure that things are ready for interaction. It's going to be unique to what you're doing.
To be honest... if this Alert keeps coming up, rather than trying to write a bunch of code to handle it, I'd want to figure out why the Alert keeps coming up and figure out what can be done to prevent it.