Setup e2e

[LivingLimes]

No description provided.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
draw-freely	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Apr 26, 2025 1:19pm

[LivingLimes]

In my latest commit, I have added a few things that should help you with debugging.

I've disabled headless mode, which opens the browser instances that you create in the test. This way, you can actually see what is happening in the test.

I have also increased the timeout of the assertions in the test. It seems to default to 5 seconds, which doesn't give much time to inspect the browser and know what is happening before the test fails.

I've also made it only run in one browser temporarily as having multiple browsers open is quite annoying when they all fail anyway.

Finally, I believe the issue is happening because the application doesn't seem to reliably take the player into a game when the page is loaded. It takes them into the game sometimes and not all the time. This happens during manual testing too. So, your job now is to figure out why that's happening so the test passes

[realtomkwok]

I figured out why the test failed, which the second player couldn't join the game automatically after the first player selected the game mode. The test was trying to access the frontend via http://127.0.0.1:3000 while the backend CORS configuration only allows http://localhost:3000 or the URL set in .env.

I changed the baseURL in Playwright's config to http://localhost:3000 and then the test passed, but I'm also wondering if there's another issue since you brought up that it happened in the manual test as well

[realtomkwok]

The last commits include the following changes:

I added a class Player for better mocking the behaviours of a real player. It creates and keeps track of separate browser contexts so each player has their own isolated session. It also has methods for actions like selecting a game mode, drawing on the canvas. Although it works, I'm not sure if it's a bit overhead in this case. You still have to initiate each player in the test and it's not much faster than creating a browser context or a page directly.

I also changed the number of workers in playwright.config.ts to 1, which prevents tests from running in parallel. If multiple tests ran simultaneously, there would be more than two players (in the test scenario) connecting to the backend, and it would interfere with the expected behaviour. I think we should add the ability in the backend like handling multiple different sessions (rooms) for different rounds of tests, or we can limit the testing worker as the last commit did.

The last two tests would fail if running the tests suite, but pass individually. I noticed there are three windows running in the second test, but none of them are the current turn player. I reckon it could be the frontend issue you mentioned earlier? I need more time to investigate it.

And I found it a bit difficult to have Playwright interacting with the canvas. So far the mouse of the page can click on the canvas, but it can't move to other coordinates to draw a line

[realtomkwok]

The last two tests would fail if running the tests suite, but pass individually. I noticed there are three windows running in the second test, but none of them are the current turn player. I reckon it could be the frontend issue you mentioned earlier? I need more time to investigate it.

I have found the problem. Last test didn't clean up the browser properly, as it should be test.afterEach() instead of afterEach(), which is a wrong hook from node:test. Will push a fix later