u/ContributionIll9303

Just saw this in the 1.63 notes. You can give a test a named lock and any tests sharing that lock name won't run at the same time, across files and workers. Everything else stays parallel.

I have a handful of tests that hit the same account settings and they'd stomp on each other in parallel. My fix was shoving them into their own project with a single worker, which works but makes that chunk of the suite crawl. Locks look like exactly the thing I was faking.

Haven't tried it yet but planning to this week. Main thing I'm curious about is whether it holds up with sharding, since the notes only mention files, workers and projects.

Anyone already moved over to it? Or found a reason it doesn't replace the serial stuff

Had one that failed maybe once every 15 runs. Everyone knew about it, everyone just hit rerun, and nobody fixed it because it never failed while you were watching.

I finally tagged it and moved it into its own job so it stops blocking merges. That helped. But now it's just sitting in a corner and I know exactly how that ends. It stays there for a year and eventually nobody remembers why it's skipped.

Curious what other people do. Quarantine with some rule for when it has to get fixed or deleted? Just delete it? Or is retry on failure honestly fine and I'm overthinking it

Had a handful of tests with sleeps scattered through them. Not proud of it. They were there because something was intermittently not ready and a 2 second wait made the failure go away, so I moved on.

Went back through them this week and most of it came down to two things. A toast that animates in, where I was waiting for the animation instead of just asserting on the text. And a table that repaints after a fetch, where waiting for the specific row content works fine and the sleep was covering up that I was asserting too early on the wrong element.

Suite got faster too, which I didn't expect since I figured it was a few seconds here and there.

The one I still haven't figured out is a chart that renders with a canvas. Nothing in the DOM really changes when it finishes drawing. Anybody solved that one without a sleep?

Spent an hour last week staring at a failure that only happened in CI. Passed every time locally. Normally that's where I start adding logs everywhere and guessing.

Pulled the trace instead and it was obvious in about two minutes. Element was there, it was just covered by a banner that only shows on the CI viewport width. Screenshot alone wouldn't have told me that, but stepping through the DOM snapshots did.

Kind of annoyed at how long I went without using it properly. I had traces on the whole time and was mostly just skimming the screenshots at the top.

Anyone got things in it they use regularly that aren't obvious? Feel like I'm still only touching a fraction of what's in there.

Feels like every release lately is aimed more at agents than at people sitting there running tests. Plenty of posts about it. I just haven't seen many people say "yeah it writes my specs now and I ship them."

I've messed with it on a side project. Selectors it picks are usually fine. What it doesn't seem to get is what's actually worth asserting, so I end up rewriting half of it anyway. Could easily be a me problem with how im prompting it.

For anyone using it for real, do you keep the output or does reviewing it take about as long as just writing the test would have

Been going through the 1.59 changelog today and it's pretty clearly not written with a person in mind anymore. browser.bind() lets an agent attach to a browser that's already running and keep the same auth state instead of relaunching one, there's a CLI debugger so something can step through a failing test without ever opening a GUI, and the trace command lets it read a trace file straight from the terminal. Basically every headline feature in this release assumes the thing driving the browser and reading the failure output isn't a person sitting there watching a headed run.

Kind of a weird moment honestly. I spent a long time getting good at reading the trace viewer, watching the video replay frame by frame, catching the one screenshot where a modal was covering the button the whole time. Now there's a CLI flag specifically so an agent can do that part without opening any of it visually. I don't think that means QA goes away, if anything I think it means someone still has to check that the agent's explanation of "this failed because X" is actually right and not just the first plausible reason it landed on. Agents are not immune to convincing themselves of the wrong root cause, they just do it faster and with more confidence than a tired human at 5pm.

Anyway, has anyone actually plugged an agent into browser.bind() yet for real work, not just a demo. Curious if the shared session thing holds up once you have more than one client attached at a time.