[somewhereoutth]

I've said it before, and I'll say it again: Interfaces used by humans must be tested by humans. These can either be your staff, or your customers.

Yes that does mean wading through each interaction pathway every time you make a release, there really is no substitute.

[technion]

I think netflix is at a scale where you can question what I'm saying below, but every frontend test suit I've seen is so full of mocks you basically only test your own test suite. And then common front end bugs like "renders off the screen" or "doesnt work in safari" aren't caught anyway.

I hugely support tests and I write a lot more of them than most people. I just don't think it usually works on the frontend.

[nosefurhairdo]

I work on fairly complex, dashboard-y, web app UI used by many fortune 100 companies. I can count on one hand the number of times the huge test suite I inherited has prevented bugs entering production. I've spent at least 40 hours debugging false positives and config issues, and about half of our deployment time is spent running these tests.

From what I can tell, there are two types of tests that are worthwhile in UI: unit tests on functions (not UI elements), and basic integration tests. I believe it's possible to write valuable tests that don't fit into this framework, but from what I can tell every other UI engineer feels compelled to write tests that just regurgitate component implementation details.