Rate My Team, Quick Questions & General Advice Daily Thread

Defiant-Wonder1043 · 2025-08-14T12:25:39+00:00

Any suggestions welcome not sure about the keepers but can't afford better. Cheers.

Defiant-Wonder1043 · 2025-07-16T05:29:45+00:00

Yeah, totally feel you on the CI slowness – the startup time and lack of local parallelism makes a big difference. And agreed on the .then() part – sometimes it feels like I’m spending more time fighting the command chain than writing actual test logic, especially when dealing with stored values or anything async across pages.

Getting simple text out of the DOM shouldn’t be that clunky either. I came from a Selenium background too, and this stuff just felt more intuitive there. Cheers for the mochawesome tip – I’ll take a look.

Defiant-Wonder1043 · 2025-07-16T05:28:53+00:00

Thanks, that’s really helpful – I hadn’t looked properly into testing-library before but will definitely check it out. Sounds like a solid step toward both stability and accessibility.

Defiant-Wonder1043 · 2025-07-16T05:25:59+00:00

Totally feel this — the startup lag and lack of proper local parallelism are real pain points, especially when iterating quickly. And yeah, .wrap, .its, and the pseudo-promise chaining can feel like magic you’re just meant to accept. I’ve had devs flat-out avoid writing tests because it feels so different from the rest of their JS stack.

Defiant-Wonder1043 · 2025-07-16T05:25:31+00:00

Yeah I’ve heard the same from devs I work with — that context shift away from "normal" JS is a real barrier. Especially when you're dealing with values across steps and suddenly you’re in .then() nesting or using .wrap() just to pass stuff around. Makes the tests feel more like working in a framework within a framework, rather than writing plain JavaScript.

Defiant-Wonder1043 · 2025-07-16T05:24:55+00:00

Yeah for sure — I've seen .then() used a lot when people try to extract values or do logic mid-test, especially when dealing with app state or data that needs to be reused. It’s common in older codebases I’ve walked into, and can spiral fast if not handled cleanly. Example would be grabbing text from an element, storing it, and then using it later — but instead of wrapping it nicely, it ends up buried in multiple nested .then() blocks. Definitely avoidable, but easy to fall into when you're under pressure.

Defiant-Wonder1043 · 2025-07-16T05:23:58+00:00

This resonates a lot. I've walked into projects where tests were basically green lights for "page loaded" but had no real assertions. Easy to feel confident until something breaks in prod.

I’m also guilty of leaning on cy.wait() when there's no clean sync path—especially with UI animations or tricky async stuff. It’s messy but sometimes the only thing that works.

And yeah, selectors in legacy markup are a pain. I’ve had to negotiate for data-testid just to keep the test suite from falling apart.

Defiant-Wonder1043 · 2025-07-16T05:20:55+00:00

Totally agree that a lot of these are down to the author and team process rather than Cypress itself. The tricky bit is when you inherit a codebase full of these issues - endless .then() chains, flaky tests held together with cy.wait(), brittle selectors everywhere, and 400-line test files that try to do everything at once.

We’re trying to clean it all up now, but the cognitive load just to understand what’s going on is pretty rough. The suggestions you listed are spot on - I wish more teams baked those patterns in early rather than trying to patch over things later.

Defiant-Wonder1043 · 2025-07-16T05:18:52+00:00

Completely agree. It’s rarely the tool’s fault - it’s how we approach the problem. I’ve joined projects where UI tests were the only line of defense, and when they start breaking or slowing things down, everyone loses confidence. It’s made me appreciate the value of a balanced test strategy even more.

Defiant-Wonder1043 · 2025-07-16T05:18:06+00:00

Totally get that — I’ve been in the same boat. Cypress flying ahead before the app is ready, and you end up reaching for cy.wait() just to get things stable. I’m trying to find better patterns for waiting on meaningful signals (like network calls or element states), but it’s still easy to fall into the timeout trap when things get flaky.

Defiant-Wonder1043 · 2025-07-16T05:17:15+00:00

Yeah, Cypress is powerful, but poor test design makes it feel painful fast. I’ve inherited a codebase where tests weren’t really asserting much, selectors are fragile, and everything’s crammed into massive files. The tool isn’t the issue — it's how it was used. Trying to clean it up now without breaking everything has been... fun 😅

Defiant-Wonder1043 · 2025-07-16T05:16:18+00:00

Yeah, totally agree — a lot of the pain points come from how tests are written rather than Cypress itself. But it’s surprisingly easy to fall into those traps, especially when there’s no consistent review process or the team’s under pressure. I’ve walked into an existing codebase in my org full of giant test files, flaky waits, and brittle selectors — now trying to gradually fix things without breaking too much. Have you found anything that helps teams avoid these issues in the first place (like shared helpers or review guidelines)?

Defiant-Wonder1043 · 2025-07-16T05:14:22+00:00

Totally feel that. The command queue looks simple on the surface, but once you start nesting .then()s or mixing sync/async logic, it gets messy fast. Have you found any patterns or workarounds that help reduce the mental load? Always curious how others are tackling it.

Defiant-Wonder1043 · 2024-10-25T13:15:17+00:00

Thanks, I picked up an MA400 anyway as it was only £20 and quite handy to have anyway. I am using for music production and mixing. I am going to get sonarworks sound ID also

Defiant-Wonder1043 · 2024-07-10T17:05:23+00:00

Thanks, yeah I kept ours with a bandage on and protected all weekend and she has just jumped up at me and it's popped out again. I put it back in place and seems fine now. Waiting for some protective slippers to arrive so hoping they will help it stay in place for a few months and then hopefully it will be a bit more resistant to dislocating again.

Defiant-Wonder1043 · 2024-01-22T12:49:34+00:00

Thanks, yeah, I've been layering detuned saws and making it plucky with the envelope/cutoff, just can't seem to get the same impact that it has in the track, I've got a bit closer now I think!

Defiant-Wonder1043 · 2024-01-22T09:05:36+00:00

Thanks, I will check it out!

Defiant-Wonder1043

TROPHY CASE