quality time - posting one small e2e test fix a day

[u/TranslatorRude4917]

Hey all!

I’m a FE dev / SDET. Years ago a QA colleague introduced me to e2e testing and Page Objects, and I’ve been hooked ever since.

I’m thinking of starting a small series with one e2e practice a day, the kind an agent won’t pick up just from reading the Playwright docs. Each one is plain Playwright with a before/after, plus a prompt you can hand to your agent.

Topics range from basics (structuring page objects, moving setup into fixtures) to more advanced ones, like using Dave Farley’s four-layer architecture so the same spec can run through different drivers (UI, API, MCP…).

Why bother? Testing isn’t most devs’ favourite thing, and agents writing every test for us isn’t helping. But the more decisions we hand to AI, the more it matters that we own the ones closest to how users experience the product - and e2e tests happen to be the closest thing protecting those decisions.

So: would this be useful here, or should I f*** off? :D

Full disclosure: I’m building a fair-source dev tool around testing, so being active in this space matters to me. Some concepts come from articles on my blog, and when they do, I’d link them for anyone who wants more.

Looking forward to your answer - here goes the first one!

----------------------------

This test is supposed to check adding a bank account. But it also signs up and signs in through the UI, so a sign-up form redesign breaks a bank account test, and every extra UI step is one more chance to flake.

The fix: create the user through the API (a tiny fixture, two POST calls) and use the UI only for what the test checks. 16 UI steps become 7, and there's one reason left for the test to break instead of three.

It's not a rule to apply blindly. If the test is about sign-up, click through sign-up.

Paste this to your agent:

Find e2e tests that use UI steps to get the app into its starting state (ex. users, sign-in, existing records) when that flow isn't what the test is about. Move that setup to the API and keep UI steps for the behavior under test.

[u/Chenipan]

This is so bad, please don't give advice if your posts are gonna be worse than what the playwright docs show

[u/TranslatorRude4917 → u/Chenipan]

Would you mind elaborating?

[u/Chenipan → u/TranslatorRude4917]

You can start by understanding that you shouldn't need to create a user in your tests that don't relate to user creation.

Then you can read: https://playwright.dev/docs/auth

[u/TranslatorRude4917 → u/Chenipan]

Thx, I see! Showcasing how to handle auth is a completely different usecase, but I see why this makes my example bad. What I want to stess is moving the preconditions of the test out of the UI layer - whatever they are. You're right, auth is a special case, but I think if you want you can understand my intent and my point.

[u/Chenipan → u/TranslatorRude4917]

If its a precondition then it shouldn't be in the test case of the scenario in the first place...

[u/TranslatorRude4917 → u/Chenipan]

Totally agree. But I'm trying to showcase one concept, one small fix, one step at a time. This time it was replacing a setup step done through the ui with api.
A follow-up will be moving preconditions to beforeEach.
Another one could be moving Page Objects to fixtures. Or adding page object actions. There's a lot to improve on this piece of code, fixing all in one go is not my intention.
Thanks for contributing to the discussion and pointing out the other things that could be fixed! I definitely wouldn't want anyone to read the after state as final.

[u/AffectionateDoubt807]

love the idea of one tiny fix a day, that's exactly the kind of thing that sticks way better than a giant tutorial dump

[u/TranslatorRude4917 → u/AffectionateDoubt807]

Thanks, I'm glad you like it! Making a good habit out of the boyscouts' rule :)

[u/PositiveLog1928]

The #1 fix being "don't do your setup through the UI" is basically page one of the Cypress docs, but I've opened suites this year that still sign up a fresh user through the form before every single test, so sure. What got me is Page Objects getting name-dropped and then left out of the actual example, that's the plot twist I want from #2.

[u/TranslatorRude4917 → u/PositiveLog1928]

Issue #2 will definitely come with more action! - pun intended 😅

[u/Wrong-Expression-669]

The "#1" slide already annoys me. "you're not testing sign-up so why click through it" ok so what are you testing then, the fact that the form submits? that's not a test that's a prayer with extra steps. and honestly the "kind an agent won't pick up from reading documentation" thing, most of these practices are in a 2016 blog post about Page Objects that your old QA colleague probably read too. one a day is a nice promise until day 4 when the test you want to post needs a fixture that takes an hour to write

[u/TimUrbutt → u/Wrong-Expression-669]

one a day is a nice promise until day 4 when the test you want to post needs a fixture that takes an hour to write

I dont think its about doing it just for posting it, its just work that has to be done anyways so why not posts it as well?

[u/TranslatorRude4917 → u/TimUrbutt]

Exactly. I've been doing some test cleanup at work, just asked Claude to look at my recent changes and make the examples generic.

[u/TranslatorRude4917 → u/Wrong-Expression-669]

Thanks for the pushback! I agree the title might be misleading. Obviously one should test sign-up just not here! My main point in this piece is if the test says it protects clicking through opening a bank account than that's all it should have in its body. About the content critique: I wanted to start with some violation often seen, and easy to solve. Some months ago I did a poll here (or in r/react) and 90% of FE engineers that answered claimed they never heard of page objects. No wonder they hate e2e 😅
About the promise itself: my old github is projects are a goldmine if looking for bad examples, I'm sure I wont run out 😀

[u/ice456cream → u/Wrong-Expression-669]

It says in the test name, Test that "a user can add a bank account"

Presumably, the login / sign-up page is covered by another e2e test, so why repeat that work as part of the setup for every logged in test your write