Condition.check is evil
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
TestPlan |
New
|
Undecided
|
Unassigned |
Bug Description
I really have a problem with "check" being a condition, since it waits for an xpath to appear up to the configured timeout.
In fact, I don't even think it can return false (it fails the test when the xpath is not there after trying up to the configured timeout), so its use as a condition is questionable from the start.
Our code code is peppered with
if check
while check
in scripts that have nothing to do with verifying the page, but rather to branch off to different execution paths based on
expected error messages showing up on the page (for example, when we activate a scheduled task, and the system says
that the start date is too early, we retry with a start date shifted 5 minutes in the future). When the error message is not there,
we couldn't care less and just want to proceed, but we in fact lose *2 minutes* everytime the error message does not appear.
This is probably one of the main causes for our smoke test running in excess of 15 hours nowadays.
To work around the problem and make it clear that we just want to check for the existence of an xpath and return immediately. we've had to add a Condition.
Solution:
"Condition.check" should become
"Check", a first class Verb that cannot be used inside an if or while, but in all other regards works exactly the same as it does now.
description: | updated |
"Condition.check" by design works exactly as "Check" does, but instead of throwing an exception sets the return value. Though it may seem like a good idea to make it return immediately, under many normal use cases it won't work.
The checkNot condition however does not wait (as it can't make sense). Therefore you could use it as a non-waiting condition:
if ! checkNot ...
We could easily add an alternate checkNoWait condition if that would be cleared.