Remove timeOut argument from verifyElement___() family of methods

This is part suggestion, part inquiry on my part as to the thinking behind the current verifyElement___() methods and their waitForElement___() counterparts, and is a conglomeration of things that myself and others harped on before (see links provided at the bottom).

As a general approach, both semantically and functionally, it would make sense that these two families of methods serve related, yet separate purposes. Specifically:

1.) verifyElement___() methods should act solely as assertions, and should perform that assertion without any timeout (i.e. should validate elements at the time they are called).

2.) waitForElement___() methods should act solely as wait conditions, and of course should take a timeout argument to realize that purpose.

The current implementation doesnā€™t exactly reflect this. Below, Iā€™ve highlighted all of the verifyElement___() keywords that accept a timeout argument:

If we look at, for example, the verifyElementAttributeValue(), and compare it with waitForElementAttributeValue(), these two can be used interchangeably as follows:

verifyElementAttributeValue(someTestObject, "some-attribute", "some-value", 30);

or

assert waitForElementAttributeValue(someTestObject, "some-attribute", "some-value", 30);

Both of these methods will both wait for an element attribute value to exist, and assert that the value exists, which doesnā€™t make any sense. Much better would be to remove the timeout argument from the verifyElementAttributeValue(), and let it act solely as an assertion (let it act on the DOM immediately), and let the waitForElementAttributeValue() do exactly what it says, and what the method name would suggest: wait. This same suggestion goes for all methods in the verifyElement___() family of methods.

Again, this is in part a question from me as to the rationale, as Iā€™m sure there was/is some rationale behind the current implementation. I also understand that changing this could be costly in terms of code impact. Iā€™m asking the question/making a suggestion based on many posts Iā€™ve seen that confuse the intended use of these methods, which I can totally empathize with.

tl;dr The verifyElement___() family of methods should not take a timeout argument, as this often makes it both semantically and functionally confused with the waitForElement___() family of methods.

Some of topics Iā€™ve seen/written recently along the same line of thinking:

Thanks guys, keep up the good work!

3 Likes

Iā€™m not so sure. The thing Iā€™ve long suspected is that, the APIs were begun by a fairly well-informed (about HTML/DOM) individual and then ā€œgrownā€ by person(s) less well-informed. Not trying to be unkind, thatā€™s just how it seems (to me).

Regarding the current framework, it is what it is and the crew will always defer to backwards compatibility - understandably so. Therefore, the only solution is a new API set where the older set are marked ā€œdeprecated in favor of ā€¦ā€ Iā€™ve said/offered this to fix the obvious footgun provided by getText/setText being entirely not what a seasoned coder might expect.

And on the topic of attribute value retrieval, when an API says it gets an attribute, thatā€™s exactly what it should get ā€“ not a property (as Iā€™ve pointed out elsewhere, attribute != property != attribute).

Thanks for the read.

5 Likes

Ok,

I am partly agree with @Brandon_Hein , verifyElement____() should not have timeOut and act on the DOM as is without timeout logic and waitForElement___() should wait the specified time. However, I think that waitForElement___() at least should have a FailureHandlig it honors so that we donā€™t need to use the assert keyword. I have tried this keyword with the assumption that it does like asserts does in regular unit tests, but there are something strange with it, some times the test doesnā€™t stop even if it should and it returns less obvious errors (This may be me using it wrong, but then itā€™s not obvious).

To honor older implementation maybe projects should have a flag for this? New projects has the flag active for new logic and old doesnā€™t, but can set it afterwards? So that when set:

  • When using verifyElement___() with timeout gives an obsolete error with recommendation using waitForElement___(). (Could also mark the timeout methods with obsolete)
  • When using waitForElement____() the default flowControl is stop but can be overridden using methods that has flowControl to behave otherwise. (as flowControl does on verifyElement___() today), having the flag NOT set would trigger flowControl as it works today.

I do agree on what @Russ_Thomas says. I have a feeling they had a good plan for these apiā€™s from the beginning, but somehow it has floated out. It may be time to create a version 2 of WebUI and clean it up to be more consistent with both how HTML/DOM works and naming?

1 Like