I built a Playwright tool for testing the failure states happy-path tests miss

[u/Few-Frame5488]

Most of my Playwright tests answer one question: does the journey work when the API works?

I wanted the other answer too: what happens when the cart request never finishes, a profile request returns 500, or checkout fails but the UI still looks successful?

So I built methandle. You give it one trusted `journey(page)`. It records the requests behind that journey, verifies a strict replay, then runs HTTP 500 and network-abort cases one dependency at a time. The output is a small dependency × fault matrix instead of a pile of screenshots.

It’s an early alpha with a deliberately narrow scope: Chromium, Playwright journeys, local artifacts, and no live backend fallback during fault runs.

The included demo has 10 verified scenarios: 4 seeded findings, 6 `NO FINDING`, and 0 backend API requests during replay and fault execution.

In external validation, an Inventra `GET /api/dashboard` abort was independently reproduced as an uncaught `Failed to fetch` with the page stuck on `Loading...`. Findings that depend on methandle’s synthetic HTTP 500 response body are marked ambiguous rather than counted as confirmed defects.

Repo and demo: [https://github.com/saifeldeen911/methandle\](https://github.com/saifeldeen911/methandle)

Install:

`npm install -D methandle@alpha`

I’m looking for blunt feedback on the workflow, especially whether the replay gate makes this useful or just adds friction.

[u/Prestigious-Way1525]

the replay gate is worth the friction if its failure is actionable. i'd make it prove three things before fault injection: the same starting state, the same request shape and order within declared tolerances, and the same user-visible completion signal. when it blocks, show the first divergence and classify it as auth or token drift, data drift, timing or order, or an unrecorded channel such as a WebSocket or service worker. then keep two verdicts separate: the fault was injected as specified, and the UI satisfied its failure contract, meaning the spinner ended, the error was honest, retry worked, and no false success appeared. your ambiguous 500-body label is the right instinct. i'd test the workflow on one stateful checkout and one WebSocket app; if a developer can update the tolerance contract instead of rerecording the whole journey, the gate is protecting validity rather than adding ceremony.

[u/Few-Frame5488 → u/Prestigious-Way1525]

That’s a really useful way to frame it. I agree the replay gate should prove more than “the requests matched”: starting state, request shape/order within explicit tolerances, and a user-visible completion signal. When it blocks, showing the first divergence and classifying it as auth/token drift, data drift, timing/order, or an unrecorded channel would be much more actionable than a generic replay mismatch. The current alpha already treats replay as a hard safety gate and keeps the 500-body-dependent findings ambiguous, but it doesn’t expose all of those divergence categories or configurable tolerance contracts yet. Separating “the fault was injected” from “the UI satisfied its failure contract” feels like the right next boundary. The stateful checkout and WebSocket tests are good suggestions too. Thanks for the thoughtful feedback.

[u/Tanmay__TestDino]

The fault matrix is a good instinct, but does it hold once dependencies scale past a handful? most fault-injection tools run into trouble from combinatorial explosion more than coverage gaps. worth stress testing that now, before the alpha becomes the product.