feat: server side mocking #34403
feat: server side mocking #34403
Conversation
There was a problem hiding this comment.
Copilot reviewed 13 out of 28 changed files in this pull request and generated 1 comment.
Files not reviewed (15)
- packages/playwright-core/src/protocol/debug.ts: Evaluated as low risk
- packages/playwright/src/util.ts: Evaluated as low risk
- packages/playwright-core/src/utils/httpServer.ts: Evaluated as low risk
- docs/src/test-api/class-fixtures.md: Evaluated as low risk
- docs/src/test-api/class-testoptions.md: Evaluated as low risk
- packages/playwright-core/src/server/network.ts: Evaluated as low risk
- packages/playwright-core/src/server/dispatchers/mockingProxy.ts: Evaluated as low risk
- packages/playwright-core/src/client/browserContext.ts: Evaluated as low risk
- packages/playwright-core/src/client/network.ts: Evaluated as low risk
- packages/playwright-core/src/client/page.ts: Evaluated as low risk
- packages/playwright-core/src/client/playwright.ts: Evaluated as low risk
- packages/playwright-core/src/server/browserContext.ts: Evaluated as low risk
- packages/playwright-core/src/client/localUtils.ts: Evaluated as low risk
- docs/src/api/class-playwright.md: Evaluated as low risk
- packages/playwright-core/src/server/dispatchers/localUtilsDispatcher.ts: Evaluated as low risk
Comments suppressed due to low confidence (4)
docs/src/api/class-mockingproxyfactory.md:5
- [nitpick] Rephrase the sentence to: "You can obtain an instance of this class via [
property: Playwright.mockingProxy]." for better clarity.
An instance of this class can be obtained via [`property: Playwright.mockingProxy`].
packages/playwright-core/src/client/mockingProxy.ts:148
- The comment 'silence it' should be 'silence it.' with a period at the end.
await route._innerContinue(true /* isFallback */).catch(() => { });
packages/playwright/src/index.ts:125
- [nitpick] The variable name
_mockingProxyis prefixed with an underscore, which is typically used for private variables. Consider renaming it tomockingProxy.
_mockingProxy: [async ({ mockingProxy: mockingProxyOption, playwright }, use) => {
packages/playwright/src/index.ts:473
- [nitpick] The error message could be more descriptive. Consider changing it to
The 'server' fixture requires 'mockingProxy' to be enabled. Please enable 'mockingProxy' in the configuration.
throw new Error(`The 'server' fixture is only available when 'mockingProxy' is enabled.`);
Co-authored-by: Copilot <[email protected]> Signed-off-by: Simon Knott <[email protected]>
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
This is awesome direction, that opens new opportunities for server components! |
That's an interesting idea. Could you elaborate on the setup you imagine for this? Would you deploy the proxy alongside your staging environment? |
We run our tests on GitHub actions over dev deployment, that is automatically built on vercel. So we pass remote import { defineConfig } from '@playwright/test';
export default defineConfig({
use: {
baseURL: process.env.VERCEL_URL, // something like 'http://build-xxxxx.vercel.app',
},
});We would be ready to deploy Playwright mocking proxy alongside the main app, to be able to mock server-side requests. Some other options I'm aware of:
|
We'd need to build that, but it's certainly possible. I'm unsure if it's needed though, because tunneling with ngrok would solve the problem as well. You'd probably write a worker-scoped fixture that uses the
I'm aware of this ongoing work in MSW, but I think it's subject to the same networking issues. If the MSW "remote server" runs on a different network than the test runner, there needs to be some sort of network link back to the test runner so they can communicate, just like with my approach. My gut feeling is that deploying the proxy alongside the application would make the feature more complicated to understand, and that tunneling with ngrok is a good solution. Curious what you think. |
|
Ngrok tunneling is the simplest setup, I agree. I see only two downsides:
I'd personally prefer to have a dedicated mocking app, that I fully control. I my project we already have similar setup for Sanity CMS, we automatically deploy Sanity Studio alongside the main app. In general, I think having kind of Playwright server / Playwright global worker is an interesting option. Besides mocking, it can conditionally perform global setup or other operations, that should be done once across the whole test run (even across shards). |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Test results for "tests 1"5 failed 19 flaky37736 passed, 649 skipped Merge workflow run. |
|
I trimmed down the feature a little more to make it easier to iterate on. Closing in favour of #34520 |
Implements #30766.
Adds a
MockingProxyclass with an API likepage.routethat allows intercepting network traffic from the web server.