| ▲ | dmd 12 hours ago | |||||||||||||
Thanks. I would love to understand what people are doing with Playwright that doesn't involve those things. I really can't recall ever using it where that wasn't what I was doing. I use it letting Claude fix things. You can't fix what you can't see! What else are people using it for? Obviously there must be a (very popular!) use case for "just clicking", but I can't seem to imagine it. | ||||||||||||||
| ▲ | Robdel12 11 hours ago | parent | next [-] | |||||||||||||
To me doing network interception in browser driven tests is a smell like that. Unless you’re running vs a full mocked server (like MSW). I’m a big fan of testing exactly like a user. Users don’t use network intercepts, timeouts, etc. All of my most reliable tests assert on DOM state. If the user doesn’t see it, don’t assert on it. | ||||||||||||||
| ||||||||||||||
| ▲ | VoidWhisperer 11 hours ago | parent | prev | next [-] | |||||||||||||
In my experience, we've used playwright significantly for unit/integration tests combining it with react-testing-library to verify individual components and also whole (mocked, we used something else that I can't seem to remember for E2E tests) flows within that React application | ||||||||||||||
| ▲ | hugs 11 hours ago | parent | prev [-] | |||||||||||||
don't underestimate the "just clicking" use case! | ||||||||||||||
| ||||||||||||||