How do Playwright's Java and .NET bindings hand a test a ready-made Page without the JavaScript runner?

Neither the JVM nor .NET has anything like `@playwright/test`, so both bindings ship a small integration layer whose only job is to create and dispose browser objects around a test written for the host runner. Knowing the exact entry point is what separates someone who has run these suites from someone who has read about them. ## Java: @UsePlaywright as a JUnit 5 extension `com.microsoft.playwright.junit.UsePlaywright` is an annotation you put on a JUnit 5 test class. It registers an extension that resolves Playwright types declared as test-method parameters: - `Page` -- a fresh page for this test - `BrowserContext` -- the context that page lives in - `Browser` and `Playwright` -- for the rare test that needs to build its own objects - `APIRequestContext` -- for direct HTTP calls alongside the browser The lifetime rule mirrors the Python plugin: `Playwright` and `Browser` are created once and reused across tests, while a new `BrowserContext` and `Page` are created for each test method and closed afterwards. You never call `Playwright.create()` or `browser.close()` yourself, and forgetting that is the usual source of leaked processes in hand-rolled JVM suites. Assertions come from `PlaywrightAssertions.assertThat(locator).hasText(...)`, statically imported; the Java binding is synchronous throughout, so there is no future or callback to unwrap. ## Configuring it with an OptionsFactory Configuration is a class, not a file. Implement `OptionsFactory`, return an `Options` object, and name the factory in the annotation: ```java @UsePlaywright(QuoteOptions.class) class QuoteTest { // test methods take Page as a parameter } class QuoteOptions implements OptionsFactory { @Override public Options getOptions() { return new Options() .setBrowserName("firefox") .setHeadless(true) .setTrace(Options.Trace.RETAIN_ON_FAILURE); } } ``` `Options` covers browser name, channel, headless mode, base URL, launch options, context options and the trace mode. That last one matters: `Options.Trace.RETAIN_ON_FAILURE` is the Java equivalent of the artefact policy a JavaScript suite would set in its config. ## .NET: the PageTest base-class chain The .NET integration is inheritance rather than annotation. Add `Microsoft.Playwright.NUnit` or `Microsoft.Playwright.MSTest` and derive from one of four base classes, each adding one layer: | Base class | What it provides | | --- | --- | | `PlaywrightTest` | the `Playwright` object and the `Expect()` assertion helper | | `BrowserTest` | adds a shared `Browser` | | `ContextTest` | adds a fresh `BrowserContext` per test | | `PageTest` | adds a `Page` in that context -- the class almost everyone uses | Deriving from `PageTest` gives a test a `Page` property and a `Context` property with no setup code, and `Expect(Page.GetByTestId("annual-premium")).ToHaveTextAsync(...)` for web-first assertions. The .NET binding is asynchronous only, so every call is awaited and every test method returns `Task`. ## Configuring a .NET run Options come from run settings rather than a factory class. Pass them on the command line, for example `dotnet test -- Playwright.BrowserName=firefox` or `dotnet test -- Playwright.LaunchOptions.Headless=false`, or put the same values in a `.runsettings` file under a `Playwright` section so CI and developers share them. ## What both shims deliberately leave out Neither one is a runner, and both stop at the same line: - no `projects`, so a browser matrix is parametrisation or a second CI job - no retries, no worker model, no `--shard` - no reporter of their own -- reports come from the host runner - no component mounting - neither reads `playwright.config.ts`; putting one in a Java or .NET repository does nothing Tracing is the interesting asymmetry. Java exposes it declaratively through `Options.setTrace(...)`, while a .NET suite starts and stops `Context.Tracing` by hand in setup and teardown. Both end up with the same trace zip; only the amount of code differs.