Hey there,
I was wondering if it would be possible to make text-based assertions, like assertSeeIn case insensitive?
A situation we've run into is that we'll uppercase something with css because of a design choice, and a test will start failing because that text is now no longer in the expected case, but the text is still the expected string, so it's not really a failure in our eyes.
Any thoughts?
My suggestion would be for you to override the method and use something like
public function assertSeeIn($selector, $text)
{
$fullSelector = $this->resolver->format($selector);
$element = $this->resolver->findOrFail($selector);
PHPUnit::assertTrue(
Str::contains(strtoupper($element->getText()), strtoupper($text)),
"Did not see expected text [{$text}] within element [{$fullSelector}]."
);
return $this;
}
You can override it only for a specific set of tests and keep the original behavior for a whole other bunch, if needed.
I think this would be the best approach to achieve what you want.
Edit: Or even maybe make your own custom method, such as assertSeeInInsensitive() and use it as you need it.
I would also like to see this, because I feel like having them case-sensitive makes the test unnecessarily brittle. If you want I can make a PR for it?
Go for it. Keep in mind that you might have to limit yourself to not make a breaking change (I make usage of sensitive assertion) while still offering the new assertion and Taylor might not accept it. It's an easy change nonetheless.
yah, I already started. Everything will be BC.
@taylorotwell I kind of agree the solution in #218 locks us into a corner, but any other suggestions how we could resolve this?
first off, i'm trying to rack my brain on other options we would put here, but I can't come up with any. any thoughts?
One option would be maybe an $options parameter. Don't love this, but don't hate it.
Another option would be adding additional methods
assertSeeCaseInsensitive()assertSeeInCaseInsensitive()assertDontSeeCaseInsensitive()assertDontSeeInCaseInsensitive()but this adds a lot of LOCs, and the method names aren't particularly pleasing.
All of this is why I suggested this as a custom method in your own extended Browser class. Dusk, as a whole, needs to attend to A LOT of use-cases and it would be unrealistic to expect that every assertion you need to make lives in MakesAssertion trait. That is why Browser is macroable and extendable. The most recent system I've been developing is reaching 100 dusk tests and 600 assertions, none of which requires sensitivity. I needed Assert See Collection, though, but I just added that in my extended browser and problem solved.
yah, so what we're discussing is the general value of specific assertions. If 99% of people would use it, it is something that should probably go in the core. If it's only 50%, maybe that's something we suggest to make macroable.
IMHO, case insensitive text assertions are incredibly common, which is why I would suggest having it in the core.
As discussed above and in the sent PR we'll probably won't add this natively in Dusk.
I had the same problem quite often (Test uppercased by CSS), so for anyone who is interested here is what I put in my Service Provider and use as waitForTextIgnoringCase:
Browser::macro('waitForTextIgnoringCase', function ($text, $seconds = null) {
return $this->waitUsing($seconds, 100, function () use ($text) {
return Str::contains(
strtolower($this->resolver->findOrFail('')->getText()),
strtolower($text)
);
}, "Waited %s seconds for text [{$text}] ignoring case.");
});
Most helpful comment
first off, i'm trying to rack my brain on other options we would put here, but I can't come up with any. any thoughts?
One option would be maybe an
$optionsparameter. Don't love this, but don't hate it.Another option would be adding additional methods
assertSeeCaseInsensitive()assertSeeInCaseInsensitive()assertDontSeeCaseInsensitive()assertDontSeeInCaseInsensitive()but this adds a lot of LOCs, and the method names aren't particularly pleasing.