allow for composite selectors and add css and index as selector types

[Castone22]

Current behavior: Providing multiple selectors to an element creation method eg

def add_static_text(class: 'foo', index: 3, element_type: :div)

Will cause it to pick the last defined selector within @@locator_elements (with no failure message making the fact that it did this very unclear)

Post Behavior: All selectors will be considered when selecting an element.

The purpose of this change is to reduce how often we have to rely on xpath selectors, as it's quite easy to write brittle and unreadable ones.

[greenarrowdb]

No description provided.

[Castone22]

@Castone22 show a couple of examples of this being used

[Castone22]

Added some examples in the last commit, and defaulted add_element to use a core_element unless you specify an element type (since often times the core-element's logic is enough validation for the presence of a structural element, they usually make pretty good parents)

147 fixes many of the warnings that show up regarding the use of wait_until_present, though the warning about using stale to detect the presence of stale elements still remains, even after latest watir (6.16.5 as of writing this). This is something on watir's side that we can't fix due to it being a little too opinionated about testing of stale elements (in this case we actually aren't testing that the element is stale, we're checking which page we're on).

[Castone22]

@greenarrowdb Something else to think about here. Often times when using parents, we don't need a selector beyond the element type, see create_account_with_parents_page.rb:15

Current implementation forces us to use one, and setting parent as a valid selector type would cause us to try to pass it to watir if i'm understanding how we pass selectors to watir.

[ThePROX]

I wanted to capture our discussion last night. Is this just waiting on a naming convention alteration or is there a substantive change that was needed before accepting this change?

[Castone22]

Something @greenarrowdb brought up in discussion was that add_element kind of looks like a default thing, what he doesn't want to happen is that we end up with a situation where someone takes one look at the add element lines and tries to create a bunch of custom logic around them to support something like a text box instead of just using add_text_box. We'll want to think of a way to mitigate this.

For now we can merge it in current state i'd say, but we'll want to add an issue to deprecate using add_element and replace it with something like add_parent_element or add_generic_element

[Castone22]

156 Tracking the refinement of this here.