Allow calling assertValue() on elements which don't support the value attribute

[u01jmg3]

Reasoning

Similar to assertInputValue() and its use of inputValue(), I opted to create elementValue(), which for a list of supported elements will retrieve the value attribute. If not it will fallback to calling getText() on the element in the same way inputValue() currently works.

Considerations

1. One scenario that is currently not possible before this PR, and continues not to be possible is a user wishing to use assertValue() against, for example, an li element and expecting to test against text between its tags. Because an li element supports the value attribute, using assertValue() cannot ever cover this scenario.
2. Although a textarea doesn't have a value attribute, its content is still retrieved using $textarea->getAttribute('value').
   • See Incomplete list of element types for function "InputValue" #633 (comment) and PR Changed inputValue assertions to check textarea element #237.

Why not use inputValue() and extend the list of supported elements?

• This method calls resolveForTyping() but not all elements that support the value attribute allow typing.
• Although it would work, inputValue() expects a variable called $field yet it would be passed $selector. This to me is messy.

Alternative Approaches

1. Add an additional assertion within assertValue() and assertValueIsNot() to check that someone is using these methods against an element that supports the value attribute. If not, throw an error.

2. Do nothing - this means users could inadvertently be calling assertValue() against an element such as a div:

   // <div class="foo"></div>
   
   $browser->assertValue('.foo', ''); // true
   
   // <div class="foo">bar</div>
   
   $browser->assertValue('.foo', ''); // true

[driesvints]

Add an additional assertion within assertValue() and assertValueIsNot() to check that someone is using these methods against an element that supports the value attribute. If not, throw an error.

I actually thought you were going to send in a PR for this instead 😅

I'm not sure it makes sense to let assertValue support elements which don't have an value attribute? @taylorotwell what do you think?

[taylorotwell]

I don't even understand what this PR is attempting to accomplish. Please try to explain the problem and solution better.

[u01jmg3]

I actually thought you were going to send in a PR for this instead 😅

I was going to but then I saw how the existing inputValue() works with the fallback to getText().

I'm not sure it makes sense to let assertValue support elements which don't have a value attribute?

Again I agree but then I saw assertInputValue() supports a textarea which doesn't have a value attribute.

[u01jmg3]

@driesvints: happy to submit another PR that throws an error. However, it seems I've confused Taylor. Assuming you know what I'm trying to accomplish, should I try another PR?

[driesvints]

Again I agree but then I saw assertInputValue() supports a textarea which doesn't have a value attribute.

Hmm, that's a good remark.

happy to submit another PR that throws an error. However, it seems I've confused Taylor. Assuming you know what I'm trying to accomplish, should I try another PR?

I talked about that with Taylor and yes feel free to resubmit but we're gonna go with your proposal to only allow elements with a value attribute + textareas.