Open medchat-layton opened 6 months ago
pavelfeldman
commented
6 months ago Could you provide exact steps of how to reproduce the scenario? It is unclear if you are using CLI, UI Mode or VS Code extension, what settings you are using, etc. I understand the feature you are after, but I'd like to understand the setup you are coming from.
medchat-layton
commented
6 months ago Ah yes sorry -
I'm using the VSCode extension. Currently if I run it in headed mode, chrome pops up, it runs the test, breakpoints work etc etc, however if the test ends and the window stays open, you lose the ability to interact with the document. Being able to still interact and have requests fire is a hugely useful thing, especially because we actually have a pretty mature enterprise testing environment that has a fully stubbed API in place, which means we can effectively use the entire application with a mocked backend with very little work. I do feel the need to reiterate that its not just post-test interaction I'd like to see, I'd also like to be able to do things while the debugger is paused at a breakpoint as you can in Cypress (since breakpoints in debug vs breakpoints in application code are different).
I'm sure a request like this isn't trivial but I'm curious if you've seen other requests for it -- I've seen nothing about it which surprised me given how huge of a feature this was for me with Cypress!
Hopefully that is helpful -- happy to clarify further if needed.
🚀 Feature Request
Make Playwright run request interception for as long as a browser window is open. It would enormously improve testing ergonomics and IMHO would make Playwright the king of all development test software, ever.
Example
In Cypress, we have the ability to interact with the page at all steps of the test - the interceptors for mock APIs are always running, whether the test is running, paused, or finished. This allows for an incredibly powerful workflow that allows you to essentially play with your application by spinning up an empty test but having stubbed/mocked APIs, but beyond that, to interact with it mid test run to debug test and application functionality.
I've found transitioning to Playwright has been extremely painful in that regard. While I overall find it far more reliable and consistent than Cypress, I actually spend on average about twice as long writing tests because I find the debug workflow very slow and clumsy, not to mention that debug is focused on your test files, not your application code.
I spent hours yesterday trying to figure out why a definitely matching stubbed request kept going to the server instead of being handled by mocks, and it turns out that it was because interception of requests stops instantaneously once your last test statement is called - that is to say, I had it click on an element, and got a 401 from our server instead of the stubbed response actually going through as expected. This was an error on my part - I should have written another assertion after the last statement, however the behavior itself is extremely confusing, unintuitive, and hard to debug given that all other tests and calls were functioning fine.
Motivation
This single upgrade would, in my opinion, change the entire game for Playwright. This has, over the last couple of years, become what I consider an indispensable part of my testing workflow with Cypress. Now that we're switching to Playwright, I was actually very shocked to find that you can't interact with it in the same way. It represents an enormous productivity hit to me, and also causes unexpected behavior in test code due to the fact that interceptors do not always fire in all contexts.