#766 text api to accept exactMatch as option

[saikrishna321]

Fixes #766

[sriv]

/cc @zabil - the introduction of new parameter in text API will break backward compatibility.

[sriv]

This will break existing functionality. Ex. currently one may have invocation such as text(selector, 'foo') and with this change foo will get assigned to option rather than args.

Another problem is that if someone used the new API and ran it against older taiko, it will not error out. For ex text(selector, {exactMatch: true}, 'foo') will result in args being [object Object],'foo'

[zabil]

I think instead of adding an option we should change the default behavior of text to only match exact. Partial matches are ok for other api's like click etc. And it's ok to revert text to exact matches.

This way there is no need to pass options

[zabil]

On further thought, this is tricky. For in the sample that you posted.

text API returns true for partial match text.

<div>Editable Demo</div>

TextAPI

text('demo').exists() // true
text('Editable').exists() // true
text('editable demo').exists() // true

exactMatch works on HTML boundary. But the HTML can be rendered in any way and look the same for example.

Editable <div>Demo</div>

How will the exact match option work in this case? I think this is the reasoning for the existing behavior.

So for this edge case. I recommend that it's explicitly handled as mentioned at #766 (comment)

[NivedhaSenthil]

Even reverting back text api to match only exact match will break backward compatibility. I feel actions that can take string as selectors like click can also accept option for partial match and the same has to be applied to proximity selectors too.

[saikrishna321]

IMO I think all the API should accept option for exact match. As mentioned here #766 (comment) if the value() returns multiple results we need to again check if the required is present in the list and perform click or any action on the text or use proximity selectors. It's getting messy now.

I prefer failing fast.

[zabil]

IMO I think all the API should accept option for exact match.

What is the definition of an exact match? Like it's mentioned earlier. HTML may look different when rendered on the page.

[saikrishna321]

text('Natural Expiry').exists() // Test Pass When the website also has the exact text.

text('Natural Expiry'). exists() // Should Fail When the html has only Expiry.

Current implementation will Pass the test as it does partial match.

I had a chat with @sriv and will fix the above mentioned problem which is for ex text(selector, {exactMatch: true}, 'foo')

[sriv]

historically we had a contains which did partial match and text which did exact match. We merged the two so now text does a first pass exact match now, and falls back to partial match.

I guess this issue is to tell taiko to do exact match only and not fallback to partial match. This might help prevent false positives.

[NivedhaSenthil]

What is the definition of an exact match? Like it's mentioned earlier. HTML may look different when rendered on the page.

With exact match we do look for text across element.

Text search works like below:
Check for exact match: matchTextNode or matchValueOrType or matchTextAcrossElements
else Check for contains: containsTextNode or containsValueOrType or containsTextAcrossElements

<p>Editable <div>Demo</div><p> will have exact match and will pick the parent element
wherein <p>Editable <div>Demo</div>Sample<p> will be matched by contains.
For text("Editable Demo").exists() will be true for both cases currently.
If we provide option to match only exact match second one will return false.