SelenideJs = TESTS automation TOOL, not a BROWSER automation TOOL
The point to have Element class over WebElement class is to have "business user oriented API" to use in tests.
What are tests?
Tests = steps + asserts
So our api is mainly: commands (used in steps) and should(condition) (used as asserts).
The only need for query style of methods like text or attribute, and predicate style of methods like isVisible, hasText - are in some "if-statement" workarounds... These cases are rare, and for them we can use Element.matches(condition) method, for example:
if (await element.matches(has.text('foo'))) {
// ...
}
It is a bit less concise, but yet readable, and more powerfull - we can't afford to reflect all conditions in built in element methods, so why then bother by adding just a few of them, like classic "webelementish" text/attribute/isDisplayed/isEnabled... ?
;)
By this we are also making our API cleaner, making it to "have only one way to perform a task".
alex-popov-tech
commented
5 years ago
Why?
SelenideJs = TESTS automation TOOL, not a BROWSER automation TOOL The point to have Element class over WebElement class is to have "business user oriented API" to use in tests.
What are tests?
Tests = steps + asserts
So our api is mainly: commands (used in steps) and
should(condition)(used as asserts).The only need for query style of methods like text or attribute, and predicate style of methods like isVisible, hasText - are in some "if-statement" workarounds... These cases are rare, and for them we can use Element.matches(condition) method, for example:
It is a bit less concise, but yet readable, and more powerfull - we can't afford to reflect all conditions in built in element methods, so why then bother by adding just a few of them, like classic "webelementish" text/attribute/isDisplayed/isEnabled... ?
;)
By this we are also making our API cleaner, making it to "have only one way to perform a task".