Comment by IanCal

I strongly disagree, but I think there are a few problems

1. Lots of devs just don't know about it.

2. It's easy to do it wrong and try and reimplement the thing you're testing.

3. It's easy to try and redo all your testing like that and fail and then give up.

Here's some I've used:

Tabbing changes focus for UIs with more than 1 element. Shift tabbing the same number of times takes you back to where you came from.

This one on TVs with u/d/l/r nav -> if pressing a direction changes focus, pressing the opposite direction takes you back to where you came from.

An extension of the last -> regardless of the set of API calls used to make the user interface, the same is true.

When finding text ABC in a larger string and getting back `Match(x, start, end)`, if I take the string and chop out string[start:end] then I get back exactly ABC. This failed because of a dotted I that when lowercased during a normalisation step resulted in two characters - so all the positions were shifted. Hypothesis found this and was able to give me a test like "find x in 'İx' -> fail".

No input to the API should result in a 500 error. N, where N>0, PUT requests result in one item created.

Clicking around the application should not result in a 404 page or error page.

Overall I think there's lots of wider things you can check, because we should have UIs and tools that give simple rules and guarantees to users.