In almost every interaction with tested application, there is a need for waiting to completion of that action i.e. to wait for reaction triggered by user interaction.
Each of this reaction should provide some visible or hidden change to the DOM tree. We can then find conditions, which describes this change.
We can say, that we are waiting for satisfying the conditions after our interaction.
For example, we have application implementing the incremental counter, which must be started first, described by this locators:
First, we need to start the counter, let's click on the button:
To ensure that we will not continue with another interaction before the latter was completed, we have to wait for satisfying the condition "counter is prepared for incrementation":
The declaration above says that we test in interval 1,5 sec. and the condition is testing that element with locator textCount is present. Note that first test for condition will start in delay of one interval (1,5 sec). If the condition is evaluated as unsatisfied after 60 seconds, the code above will raise the timeout exception.
This unreadable section can be easily modified to be pretty more readable, using capabilities of Graphene Utility, and we will continue to present this method of improving readability:
So we have satisfied that counter was started, and it should be definitely preset to value zero:
Let's try the functionality of button Increment:
After this step we will need define another condition, which will be satisfied after increasing the value of counter to "1" - for this purpose, we will create own condition object, reusing the predefined condition of type TextEquals:
Let's use this condition in action:
It's obvious, that with waiting for satisfying each condition, we also assert that the condition has to become true to successfully continue in current test. There is no need for additional assertion on value.
Sometimes however we need to wait for value that is unknown in time of interaction. There comes Retrievers into play.