Condition.check is evil

[Stephane Mikaty (eCircle AG)]

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.xpath_exists which does not mislead the reader anymore.

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.

[edA-qa (eda-qa)]

"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.

[Stephane Mikaty (eCircle AG) (s-mikaty)]

check is a verb that suggests something nasty will happen if the outcome
of the test is failure (akin to "assert").

Would you write this?

if assert ...
...
end

On 11/06/2010 02:23 PM, edA-qa wrote:
> "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.
>

Stephane Mikaty
Quality Assurance

eCircle
P: [phone] | F: [phone] | E: <email address hidden>
Nymphenburger Str. 86, 80636 München

Stay in touch
Web: www.ecircle.com/de | Newsletter: www.ecircle.com/index.php?id=63&L=0

Für Hilfe mit dem eC-messenger wenden Sie sich bitte an unseren
Support unter Tel [phone] oder <email address hidden>

Neuste Untersuchungen
Ein unschlagbares Doppel: E-Mail-Marketing & Webanalyse
Download Whitepaper: www.ecircle.com/index.php?id=61&L=0

eCircle GmbH, HRB 184 478, Handelsregister München, Geschäftsführung: Volker Wiewer (Vorsitzender),
Alexander Meyer, Thomas Wilke, Vorsitzender des Aufsichtsrates: Dr. Arnold Bahlmann