Is it possible to combine Playwright and LiveView's DataCase for end-to-end testing?

Phoenix Forum Questions / Help
, , , ,
1

TLDR: I have a page that is partly rendered on the server and partly on the client. I am looking for a good way to test this page. Can I somehow end-to-end test the page, while using test environment-only data fixtures?

Playwright is a framework for testing web applications end-to-end. There is a part of one of my live views that I cannot test with LiveView’s built-in tests only. At least, that’s my suspicion.

Here’s a dumbed down version of the behaviour that I am testing.

A live view renders a large text as pages on the client. The client renders one page at a time. Scrolling is not possible, because the rendered page adjusts to the dimensions of the containing html element.

Currently, I have a fully functional live view. But… I took the “build first, test later” approach. There is one part of the live view that I want to test from “end to end”. That’s the following part of the implementation:

A live view sends a text to the client. This text might overflow it’s containing div. The client adjusts the text to render the UI properly and sends back a short report to the live view. The live view needs this report to handle a certain client event.

I am looking for a good way to test this behaviour/implementation. Testing with Playwright across many real browsers works well. But how can I use a fixed test environment-only dataset to use alongside the Playwright framework?

As the title of my post suggests, I have considered that maybe I can use LiveView’s DataCase somehow? I am, however, not sure how. And whether that is a good way to approach the problem.

The implementation of the desired behaviour might seem a bit odd, considering alternatives (in case you can tell from the little information in this post). I case you are interested, I am indeed looking for better implementations. Currently, I am not using LiveView’s streams. However, that might very well be a better way forward.

2

Btw, Playwright test code looks like:

import { test, expect } from '@playwright/test'

test.describe("something", () => {
  test("A", async ({ page }) => {
    // some browser behaviour
    // refute or assert something
  })
})

Testing localhost:xxxx and https:// are both possible.

3

You can use Phoenix.Ecto.SQL.Sandbox — Phoenix/Ecto v4.4.2 to integrate the ecto sandbox with any e2e test tooling, but you’ll need to setup any data you need for the test run through the UI.

If you also want to be being able to setup the db state directly something like wallaby (maybe with a playwright driver as an alternative to chromium/selenium) seems like the better option.

4

Oh I see. So, for example, a user is registered through the UI using an end-to-end framework, and that user is inserted into the sandbox, rather than to the actual database?

Do you have any tips or resources at hand for how I can best start figuring out how to set this up? I am new to simultaneous production, testing and deployment, so still getting familiar with how to handle test, development and production environments alongside each other.

I’ll start with the documentation.

5

I initially thought you were referring to WallabyJS. But following the link you sent me I see you were referring to the Wallaby hex package.

I’m not tied to Playwright so I’m def checking this out in detail. Thanks.

6

The sandbox is the actual database. Ecto creates a “sandbox” within postgres by starting a transaction, routing all reads / writes for that test case into that transaction, and then ROLLBACKing that transaction at the end.

1 Like
7

Oh, yes. That’s right.

Also, I just wanted to mention that I have Wallaby up and running now, and it really is exciting how well it integrates with my prior “mix test”-tests. And from a first glance the options and syntax seem great.