1

So I have this Selenium-based test suite written in Java. We are doing functional/integration testing, not unit testing. The test suite is a string of operations and each operation depends on the state of the UI at the start. If the previous operation did not leave the UI in the correct state, recovery is needed, sometimes non-trivial.

Ideally, the logic of the test suite would ensure that the state is correct every time. However, with various error/exception execution paths this becomes tricky to ensure manually. If I put in Page Object Model (currently not used, because each page is only used by one place in the code anyway, but this might change), tracing the state manually might become even harder.

I'd like to store the current state somewhere, so that any code that changes the state (opens/closes a dialog, etc) could modify this state, and any code that needs a certain state might check whether it is correct (and recover if it is not). Of course this is still not error-proof, as I might set the state incorrectly in some code. But at least if NoSuchElement exceptions start, I can check if the stored state is real and chase that up.

But how do I store the state? The only thing I can think of now is a global variable, probably stored in the driver manager helper object, with an enum in it. But this looks somewhat ugly? Might there be a better way?

I did look into POM guides online but they just propose asserting the state based on autodetection, for example, the title. However, if the assertion fails, there is no way to find out the actual state and recover. In theory I could write a massive DetectState method with autodetection for every state I know, but I'm not sure this is a great idea.

1 Answer 1

1

Your test would be simpler if they all start from known good position. Don't attempt recovery: any such effort will be inherently fragile.

  • Test might fail in subtle unanticipated ways making recovery wrong (for that failure only), causing following tests to fail.
  • You may have a bug in recovery code, making following valid tests fail.
  • end product of the test run will change, so you will have to change (and debug) the recovery.

You will waste time fixing recovery code. Instead, spend time to make flushing all changes made by test and starting with "clean slate" faster. It scales better.

Compared to unit test, UI test are harder to make independent, so I just tend to make fewer but longer running test. Some of my functional tests run for 10 minutes or more, because it takes a long time to prepare set of conditions to be tested.

So it is hard choice to start new test (which might require long run to prepare conditions), or just pile up new tested feature on top of another test which already made necessary efforts to prepare the conditions.

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.