Comment by hugs
> inject js, modify the DOM, and most crucially monitor/modify network requests
not yet. definitely on the roadmap, though. goal is to embrace what playwright has done well, then extend what's possible...
> inject js, modify the DOM, and most crucially monitor/modify network requests
not yet. definitely on the roadmap, though. goal is to embrace what playwright has done well, then extend what's possible...
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.
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 built an entire career on the "click" case (just making a button work). no wonder, the vibium go binary us called "clicker".
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.