Handle stale or invisible elements automatically in acceptance tests #4718
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Commands executed on Mink elements may fail for several reasons. ElementWrapper is introduced to automatically handle some of those situations, like StaleElementReference exceptions and ElementNotVisible exceptions. StaleElementReference exceptions are thrown when the command is executed on an element that is no longer attached to the DOM. When that happens the ElementWrapper finds again the element and executes the command again on the new element. ElementNotVisible exceptions are thrown when the command requires the element to be visible but the element is not. When that happens the ElementWrapper waits for the element to be visible before executing the command again. These changes are totally compatible with the current acceptance tests. They just make the tests more robust, but they do not change their behaviour. In fact, this should minimize some of the sporadic failures in the acceptance tests caused by their concurrent nature with respect to the web browser executing the commands. However, the ElementWrapper is not a silver bullet; it handles the most common situations, but it does not handle every possible scenario. For example, the acceptance tests would still fail sporadically if an element can become staled several times in a row (uncommon) or if it does not become visible before the timeout expires (which could still happen in a loaded system even if the components under test work right, but obviously it is not possible to wait indefinitely for them). Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
danxuliu
changed the title
|
As this is CI only for the acceptance tests and has purely the goal to make them more stable I will merge this one now. |
MorrisJobke
deleted the
handle-stalled-or-invisible-elements-automatically-in-acceptance-tests
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is the last of the needed changes to fix/minimize the sporadic failures of the acceptance tests (or I hope so; there may be other different sporadic failures that have not manifested themselves yet ;) ).
Sometimes, acceptance tests fail because a StaleElementReference exception is thrown when executing a command on an element (
Element is no longer attached to the DOM). This can happen even in an apparently safe chained call like$actor->find($locator)->click(); in the milliseconds between finding the element and clicking it the element could have been removed from the page (for example, if a previous interaction with the page started an asynchronous update of the DOM). Ah, the beauty of concurrency... :PIn other cases, acceptance tests fail because an ElementNotVisible exception is thrown when executing a command on an element that should be visible but it is not (
Element is not currently visible and so may not be interacted with). Finding an element only guarantees that (at that time) the element is attached to the DOM, but it does not provide any guarantee regarding its visibility.It is possible to handle both exceptions in a generic way: a StaleElementReference exception can be handled by finding the element again and executing the command on the new element, and an ElementNotVisible exception can be handled by waiting for the element to be visible and then executing the command again. Therefore the ElementWrapper class was introduced to wrap Mink elements and automatically take care of those situations.
However, the ElementWrapper is not a silver bullet; it handles the most common situations, but it does not handle every possible scenario. For example, the acceptance tests would still fail sporadically if an element can become staled several times in a row (uncommon) or if it does not become visible before the timeout expires (which could still happen in a loaded system even if the components under test work right, but obviously it is not possible to wait indefinitely for them).