2

I am currently using protractor but the idea would be similar for any flavor of Selenium. Right now, depending on which step the test is on, my current framework will wait for elements to be interactable before proceeding. What I would rather do is explicitly fail if the test encounters some unexpected behavior.

For example, let's say I am filling out a form and expected behavior is that when the form is submitted I am redirected to another page in the app. Typically, I will wait for the next element I want to interact with to be enabled in such a way for me to do that. Now, assume something went wrong with the form and instead of proceeding I get an error (i.e. red toast) and the form doesn't get submitted or the page doesn't redirect. The problem I've noticed in this scenario is that the test will wait for the element, hit the default timeout and throw an error, then it will attempt the next step in the test, hit the timeout and error, and so on. Instead of doing all this waiting I would rather explicitly fail and move on to the next test.

I'm looking for ideas on how to explicitly fail in this scenario and how to make the mechanism for failing reusable so it's not scattered all over my framework. Anyone done anything similar to this that worked well?

I've used protractor-fail-fast before but I don't want to use that in this situation. That package will abort the entire test run on the first error/failure. In this case, I want the full suite of tests to run, I just want a specific test to immediately fail and move on to the next test when it encounters some unexpected behavior in my app. I know I will need a custom solution but I'm having trouble thinking through what that solution would looklike. Looking for ideas...

Improve this question
7
  • 1
    I can't answer the question, as I don't know anything about Protractor tests yet. I'm familiar with other automated testing though, and can say Protractor should automatically be failing the current test case and moving on to the next on any fail/error. There's been a bug open for this for 2 years: github.com/angular/protractor/issues/3234 Last update suggests if you're on the latest Protractor maybe it just works correctly now. Good luck!
    – anonygoose
    Commented Mar 12, 2019 at 15:32
  • Hmmm, yeah not quite what I'm looking for. It's working fine if an assertion fails. That's completely different. I'm talking about a situation where you need to complete a certain number of steps in the test case before you get to the assertion and one of the steps has failed. Making it impossible to complete any of the additional steps before the assertion. I want to fail the test on the first step that fails and move on instead of waiting for all the steps to run their course and then fail on the assertion.
    – tehbeardedone
    Commented Mar 12, 2019 at 16:09
  • I guess a better way to describe it is that if I use ExpectedConditions.visibilityOf() or ExpectedConditions.elementToBeClickable() the test will not fail if these functions timeout before the element is visible in the DOM or becomes clickable. It just throws a timeout error and moves on the the next step. Looking for some ideas on how to explicitly fail if something like that happens that could be reused for multiple scenarios. Maybe I'm overthinking it. I don't know. Just having a hard time picturing how this would work.
    – tehbeardedone
    Commented Mar 12, 2019 at 16:17
  • +1Excellent question.
    – Vishal Aggarwal
    Commented Apr 13, 2019 at 9:00
  • Why would a next test start if the first one throws a TimeoutException? If something like this is thrown, the test fails and results in an error. Unless the second test is dependent on the first one, it should not matter, if it is then this is what should be fixed as making test dependent on each other is bad practice.
    – Moro
    Commented May 9, 2019 at 4:27

1 Answer 1

Reset to default
1

Implement exception handling.

The solution in these scenarios which worked for me is, checking for console errors on each form submissions( post requests) and raising the JavaScript error which needs to caught on global framework level so that solution is not scattered all over the framework and raised from individual 'it' blocks and caught on global framework level code which will be executed on after each 'it' block completion.

This global code on detecting an (raised ) JavaScript error will immediately fail& terminate the current test and move on to the next test in the suite for the execution.

The key is to understand the AUT's internal structure and setup the hooks at the right places.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.