Add Playwright driver

[ftes]

@germsvel I know you're working on this anyway. I'm just leaving this here in case you want to have a look.

I wanted to play around with playwright a bit to get more input for my upcoming CodeBEAM talk.
Fairly smooth sailing so far. I see you've been active in playwright-elixir getting things ready 🙂 .

[ftes]

Playwright treats exact: false as case insensitive. PhoenixTest remains case sensitive.

[ftes]

This just overwrites the conn context field with a playwright page.

Probably not the best way of doing this.
Just chose this as it was minimally invasive.

[ftes]

Mostly copied from PlaywrightTest.Case

[ftes]

Add text first, them remove.
Otherwise this is a no-op when using playwright.

[ftes]

Workaround for #142

Implicit and explicit labels not treated equally by Live and Static drivers: explicit wins, no error is.

But Playwright treats them equally and raises an error.

<label for="email">Email</label>
<input id="email" name="email" />

<label>Email<input type="email" name="email" /></label>

[ftes]

Cache?

[ftes]

Add docs (API tbd)

use PhoenixTest.Case,
  playwright: chromium,
  headless: false,
  slow_mo: 500

[ftes]

mix playwright.install made set up in CI easy :) No caching yet tho.

[ftes]

I don't think we need to use much of what playwright-elixir offers (or will offer in the future).
Idea: Talk directly to the playwright server. Implement only the relevant parts of the Websocket protocol.
Maybe I'm being naive and playwright-elixir is already doing more heavy lifting relevant for this use case than I think.

Somewhat comparable to cuprite. Buth with playwright (server) as an additional abstraction (component) inbetween, instead of raw CDP.

[germsvel]

Talk directly to the playwright server. Implement only the relevant parts of the Websocket protocol.
Maybe I'm being naive and playwright-elixir is already doing more heavy lifting relevant for this use case than I think.

Somewhat comparable to cuprite. Buth with playwright (server) as an additional abstraction (component) inbetween, instead of raw CDP.

That's exactly where I landed too. I don't know if I'm misrepresenting what playwright-elixir is doing for us, but I like the idea of cuprite.

I started exploring that (even started creating a project to handle Elixir <-> CDP communication through websockets), but had to halt due to time constraints.

So... now, I don't know if we need Wallaby or Playwright. It would be cool (but not sure if a ton more work) to create an Elixir CDP wrapper that allows us to communicate with chrome (kind of like ferrum which cuprite uses). And then PhoenixTest just uses that.

[ftes]

Elixir CDP wrapper: bitcrowd/chromic_pdf might be a good starting point.

But I still think "vanilla" playwright (not via playwright-elixir) might also be a good option.
Higher-level abstraction (less for us to implement?), multi browser support out of the box, tooling (e.g. installing browsers).

[germsvel]

Elixir CDP wrapper: bitcrowd/chromic_pdf might be a good starting point.

Oh cool. I didn't know about that package. I'll take a look.

But I still think "vanilla" playwright (not via playwright-elixir) might also be a good option.
Higher-level abstraction (less for us to implement?), multi browser support out of the box, tooling (e.g. installing browsers).

Yeah, that's an interesting idea. I didn't realize that's what you had suggested at first (though, now I see it 😄 ). I like that idea too. I can see how we need maybe 1/10th of what playwright-elixir is trying to do. We could do it directly with playwright, and leverage what we already have in phoenix_test the way you have been thinking about implementing Wallaby and Playwright-Elixir (meaning, we rely on render_html a lot and then do assertions and stuff like that on our side)

[ftes]

Closing in favour of #145