> 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...

▲

dmd 12 hours ago | parent [-]

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.

	▲	mewpmewp2 7 hours ago \| parent \| next [-]
		I guess the issue is that real world does smell terribly. I wish I could just have the perfect World like my side projects always have, but not the case with the commercial ones making money.
	▲	dmd 11 hours ago \| parent \| prev [-]
		Almost nothing I do has to do with what users actually see though. It’s all things like “why didn’t the SSO flow work”.

▲

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!

	▲	therunninglight 11 hours ago \| parent [-]
		hugs built an entire career on the "click" case (just making a button work). no wonder, the vibium go binary us called "clicker".