playwright is solid but i spend more time fixing tests than writing features
Posted by its_mayank0708@reddit | ExperiencedDevs | View on Reddit | 82 comments
Been using playwright for about 8 months now, it's definitely better than selenium and cypress in terms of speed and reliability but i still find myself spending way too much time on test maintenance.
The tests themselves run great, super fast, good API, love the tooling. But every time we do any kind of ui refactor or design update, I'm back in the test files updating locators. We use data-testid pretty consistently but even then, components get renamed, page structures change, new modals pop up unexpectedly.
I'm at the point where i'm wondering if there's something with less maintenance overhead. I've looked at some of the newer tools that claim to handle this stuff automatically but haven't pulled the trigger yet.
For context, we're a team of 6 engineers at a series a, building a b2b saas product. We have about 150 e2e tests and growing. The tests are valuable when they work but the maintenance burden is starting to outweigh the benefits.
Curious if anyone else has hit this wall with playwright or if i'm doing something fundamentally wrong?
lastesthero@reddit
The maintenance tax is real and it doesn't really go away with better locator strategies — it just shifts. We use data-testid everywhere and still break 10-15 tests per sprint because structure changes, not because selectors are wrong.
What helped us more than anything was treating the screenshot as the primary assertion instead of the DOM. If the user sees the right thing, the test passes. Eliminates the whole category of "button moved 10px" failures that aren't actually bugs. Still not zero maintenance but it cut our fix-broken-test time in half.
sheshadri1985@reddit
You're not doing anything wrong — this is the wall every team hits around 100-200 tests. Playwright is the best E2E framework out there, and
data-testidis the right call. The problem isn't your tool choice, it's that manual test authoring doesn't scale.Here's the math: 150 tests × UI refactor every 2 weeks = you're running a second codebase that needs constant synchronization with the first one. At a 6-person Series A, that's brutal. You're paying senior eng salaries for locator maintenance.
Things that help within Playwright:
getByRoleoverdata-testidfor elements that have semantic meaning.getByRole('button', { name: 'Save' })survives component renames, testid changes, and restructures. Reservedata-testidfor elements without clear semanticsexpect(locator).toMatchAriaSnapshot()catches structural regressions without brittle selectorstest.fixme()ruthlessly — mark broken tests immediately instead of letting them block the pipeline while you fix locators during a sprintThe deeper issue:
You have 150 tests that a human wrote by looking at the UI and choosing selectors. Every design change invalidates some of those choices. This is a losing war — your app changes faster than you can maintain tests for it.
What's starting to work for teams in your position is automated test generation — instead of hand-writing tests and maintaining them, you generate them from the current state of the app. UI changes? Regenerate. New modal? It gets picked up automatically.
I built AegisRunner for exactly this problem. You give it a URL, it crawls every page, form, and interaction in your app, then generates Playwright specs with semantic selectors (roles → aria-labels → text → testid → CSS as last resort). When you ship a redesign, you re-crawl and get updated tests instead of manually fixing 30 broken locators.
We've tested it against production sites — 25K+ generated tests at 92.5% pass rate across Next.js, Nuxt, Svelte, and Angular apps, zero manual authoring. For a B2B SaaS with 150 tests, the crawl takes a few minutes.
Free scan at aegisrunner.com — no signup, drop your URL and see what it generates. At minimum it'll show you which selectors it picks vs what you're using now, which might be useful even if you stick with hand-written tests.
But honestly, even without my tool — switching from
data-testidtogetByRoleas your primary strategy and putting selectors behind a POM layer will cut your maintenance in half right away.Daniel456Garcia@reddit
Once we improved our playwright ci integration to track which locators fail most, we could focus refactoring on actual problem areas.
AudienceOwn3845@reddit
ugh feels like you are spending more time fixing selectors and broken tests than writing real code. you might try using mondaydev to track test status and automate repeat work so the noise doesnt drag down feature development. batching those annoying tasks into automated, tracked issues could free you up to actually ship the stuff that matters.
SlightReflection4351@reddit
okay been there i’d use monday dev to ease test tracking and toss those annoying tasks into auto so life moves on and you focus on shipping big stuff
m_corleone_22@reddit
Not doing it wrong, this is just life with E2E tests at scale.
would you outsource Playwright maintenance entirely? Someone else keeps your tests running, you never touch them?
What would make you say yes vs no?
(being honest - validating squashqa.com, this is exactly what we do)
Venthe@reddit
In short - you'll face the same issues in any UI testing tool.
First and the most important question: Why are your tests breaking? Because renamed components or page structure changes should not break your tests. Unless you change or remove a crucial element (next button, form field) moving things around should not break them.
Second, what are you testing with playwright? While you can verify each and every single text instance on your page; this will have high signal-to-noise ratio; and can be tested with unit tests.
Keep the playwright to test the business flows and site behaviour, not any particular specific element unless it is dependent on the integration.
bluemage-loves-tacos@reddit
This is pretty important IMO. If the behaviour changes, the tests *should* break. If the bahviour is not changing, just the styles or layout, then the tests shouldn't really nueed much if any updating.
If lot of test breaking for such things, it is an indicator of a different problem, that the wrong things are being tested for.
tehsandwich567@reddit
You are not writing tests in a sustainable manner.
Your locators should user testing-library like selectors where you are selecting like a human does - via on screen text.
Anything else and you are testing implementation details of html
Venthe@reddit
Found it more problematic than it's worth, but credit where credit is due, the playwright team advises against data-test-id
tehsandwich567@reddit
Oh. It’s horrible. But it’s the best solution so far
aLokilike@reddit
No it's not. The writers of every testing library tell you not to use test ids. But here you are, saying they're right and it's horrible, but it's still the best solution so far? Did you run out of ideas after trying nothing?
jascha_eng@reddit
I do feel like they are more reliable than specific selectors. Texts and even element types can change but as long as they have the right test id, it continues to work. I get that this means my app code is polluted with test data but eh I don't see that as too much of a problem and the stability of my test suite is worth it imo
ch34p3st@reddit
Our selectors are role + text based, and use the same interface for fetching translations from json. If the copy changes, our test remains stable.
aLokilike@reddit
What it indicates to me is that your website isn't very accessible, because there aren't predictable structures to work with. It could also just mean that you're rapidly changing, but you said that the test ids still exist so that doesn't make sense.
davvblack@reddit
otoh, changing the displayed label of a button breaking tests is equally annoying
Venthe@reddit
For me the main problem is that - in our example - we are building a service in a mixed team for a German client; where most of our dev team does not speak german. Text locators are an active detriment to the understanding. Data-test-id for us was the correct choice
T_D_K@reddit
Sounds like you need to go whole hog and pull your text out into a resource file. Then your test and your UI can point to the same named value. Button text changed? No problem.
Also, make sure your end to end tests provide value. A few tests that do a complete, semi complex walk through of you app is way better than a melange of small, single page or partial page "end to end" test. Leave that to unit tests if you want them.
Mr_Willkins@reddit
It's convenient but not a good idea imo. Say someone accidentally adds or removes a character from one of the strings in the shared file. It's a big PR with lots of changes, but you can relax because the text coverage is good, it gets waved through. Whoops.
To avoid this, your 'expects' should be completely independent - a snapshot of that is decoupled from the app data as much as possible. No shared constants, just plain stems strings and objects.
T_D_K@reddit
I do understand what you're saying. But I think its a bad idea to make end to end tests dependant on copy editing concerns. That's a whole different issue with its own solutions... unit tests maybe, or better yet assign copy editors to PRs containing changes to resource files.
Mr_Willkins@reddit
In principle, sure, but in practice - how often are your button text and aria labels changing?
Venthe@reddit
That's something that I actually did not consider; I'll need to ponder on that for a while.
T_D_K@reddit
The idea is a light weight version of internationalization (i18n). Might be overwhelming to dive in headfirst, i18n is a whole can of worms. But I think you might be able to find some value in the basics.
Venthe@reddit
Oh no, don't get me wrong; we do have i18n in place; only the thought about sharing the translation files between FE and E2E didn't occur to me :)
30thnight@reddit
This is the key reason you want to use accessibility based role selectors over test-ids. You can mix both but the a11y roles should be the predicate.
Nezrann@reddit
Wrap any selector logic with labels instead of html DOM nonsense.
aria-label = "target"
sayyouresorry@reddit
You're likely not following selector best practices - you should be using getByRole for 99% of your selectors. Using the appropriate role and aria labels for your components means you can select and test as your user would - refactoring should rarely cause failures in this case as you'd be testing the functional behavior of the feature. Using data test IDs, classes, anything that depends on a specific Dom order/structure and even text are subject to flaking. You should be able to rewrite an entire feature, but if the functionality hasn't changed, the tests should still pass. If they don't, it's likely how you're selecting your elements.
Prioritizing role selectors and aria labels also has the amazing benefits of making your product significantly more accessible for people using your site with screen readers or other accessibility tools.
RTL's priority guide is a great outline for how to choose your selectors: https://testing-library.com/docs/queries/about/#priority
WhenSummerIsGone@reddit
aren't test-ids more stable than roles or aria labels, allowing more flexibility in updating the app without breaking tests?
sayyouresorry@reddit
They allow you to ignore how your app is used, and write test coverage with less value. You may miss key interactions, or perhaps your tests would continue to pass in circumstances where they should fail. If the user experience is unchanged, they should be still pass, but inversely you also want them to fail if the user experience changes. Datatestids are an escape hatch around writing better test coverage.
WhenSummerIsGone@reddit
ok this makes sense. I need to think more deeply about a refactoring project I'm planning. Many old tests use locators based on class names, which is definitely a problem. I thought test ids were the fix. Hm...
jascha_eng@reddit
My experience as well. Change from tabs to a drop down or another menu and your selectors break. Test IDs can continue to work. I don't understand the hate against them.
sayyouresorry@reddit
I would want my UI tests to fail in the case of a major change like from tabs to a menu. Imo I shouldn't need to make my code consider how my tests will be written, it should be as easy as changing the roles in my tests from from menu/list to tablist to reflect the new expected behavior.
sayyouresorry@reddit
Playwright also uses getByRole in their best practice documentation: https://playwright.dev/docs/best-practices#best-practices
explodingfrog@reddit
I get the thinking that having a lot of e2e tests seems to "replace" unit level tests, but I've found that having many more unit tests than e2e tests to be one of the most beneficial changes to a codebase to make.
pseudo_babbler@reddit
I would recommend a few things:
stop using data-testid unless you have to (like, it's an icon in a list or something). Just use the text on the button or clickable item. It doesn't change as much, and if it does change it means you genuinely changed your your app works and therefore need to change your tests accordingly.
Run the tests as a pre merge check and disallow merging unless it passes.
Once the tests start to take too long, put time into splitting them up to go faster
One even the split tests take too long, start getting smart about testing many things in a single flow. It goes against traditional unit tests wisdom, but the benefits of years that are practical to run in the build outweigh the downsides of not having atomic tests.
thats_so_bro@reddit
Button text is an implementation detail... data-testid is literally the easiest way to allow app structure to change, details to change, and still maintain that a test is doing what it's supposed to do: test functionality.
Also disallow merging is kinda meh. Tests are a code smell, not an authority. Could be better for some teams, but in general I don't think it's always needed.
pseudo_babbler@reddit
I think that you will find that the text on screen - button text, page headers, section titles don't actually change as much as you think, and using just the text makes everything simple. The text on the screen is basically the opposite of an implementation detail. It is a customer facing detail that 100% affects how the user uses the app. An implementation detail implies that there are other ways to implement the logic with the same result for the end user.
The tests also read better (though, you should use page objects to define the interactions for a page anyway) and you don't have to worry about using off the shelf components that don't have data-testid in them, or in the right element.
Preventing merging means your tests always work, it means devs don't sit around whingeing and being lazy. Well, they'll still whine about having to fix tests but that's just like kids complaining about having to do work, as opposed to everyone getting shitty with each other. Once again, you're using dev words but in the wrong way. A test failing is not a "code smell", it is absolutely possible to write automated browser tests that always test the app correctly, and if they fail it is extremely likely that something in the app broke.
The worst situation you can get yourself in to is to have a massive suite of slow automated tests that are unreliable and flaky and rely on attributes that change without being able to see them change (test failed with "can't find element [data-testid=subheader-item-selected]" is a much worse error message than "can't find text [9 items in your cart]")
You end up just burning time running them and fixing them without them ever really catching a single useful bug. You've got to do it properly or not at all. Imagine if your unit tests failed and you said it's ok it's only a code smell! Or maybe you do?
thats_so_bro@reddit
Text changes a lot where I work. Yes, the users see it. In a pragmatic sense, it is the exact same reason that you're not supposed to test for implementation details that you should not test for text. Something that changes which doesn't affect functionality that will break tests that shouldn't. It does not affect how the app works. Changing text on a website should never, under any circumstance, lead to a broken site. Yes, a user may click things in a different order, but a robust app allows for that. Testing should cover all flows (or at least all flows that matter), so if a text change affects the user's path, the test should still handle it. If it doesn't, that's not on the text change. That's on shitty tests.
Data-testid is simple to add, and almost all component libraries should allow you to pass it in. By convention, a locator shouldn't break unless the data-testid changes. You have guaranteed uniqueness and simple queries. You could argue that it bloats code, but it allows you to change virtually anything and the test will still pass so long as the test is well constructed. As for readability, I don't understand how not being able to find the text is better than not being able to find the testid. Hell if anything, the testid message is superior. If you name them well, it gives you semantic information about the source. A text message could be incredibly generic, repeated somewhere else in the app without uniqueness, and could quite honestly tell you absolutely nothing. Especially if you're working with code that someone else wrote.
Yes, it's not a code smell in the sense that it's not poorly designed code that will eventually lead to a bug, it's just poorly designed tests that will need to be constantly updated. I was kinda hoping you would just understand what I meant without being pedantic.
The merging thing is kind of whatever. I'm really here nor there on it. My point is just, have you ever merged code that you knew would work even though a test was failing? I think it's fine in some circumstances to allow a quick merge and fixing things after, and I personally like having the emergency hatch.
pseudo_babbler@reddit
All good, it's probably just an agree to disagree on this one, at least for test IDs. If it was a codebase that already used them then I would happily use them, but if I had my way I would not. On merging, on the other hand no, if they weren't running as a merge check and they were failing intermittently because "we'll fix them later, I know it works" then I would strongly argue for deleting the entire automated test suite with the justification that the dev culture isn't mature enough for it.
thats_so_bro@reddit
Fair enough. To your last point, I actually agree. Was thinking about it more under the guise of: we need to X change in fast, but some test is failing, just merge it and we'll fix the test immediately after. If it's tests failing almost every PR and merging anyway, obviously that's a problem.
Mr_Willkins@reddit
Having to rely on test IDs is a bad smell. Your users can't see them. You should spend more time adding more user-facing selectors to your UI, If necessary, use them for top-level sections that don't often change,then select within them.
LookAtYourEyes@reddit
As a QA Automation Engineer, this is an ongoing problem that everyone is trying to fix all of the time. My only suggestion is to take ease of testability (when designing) as seriously as you would any other non-functional requirement like performance or user experience.
One thing you could do is try to focus less on e2e tests as a whole. They are the flakiest and only should be written for mission critical features and functionality. Go wide with unit, integration, functional tests, but e2e and UI tests should be prioritized with a more strict acceptance list. Focus on things likely to break, not just everything and anything.
Also, simple trick is to use the
data-testidhtml attribute on your components and html elements wherever possible. Keep a lookup table of some kind, make sure everything is unique, then when someone is adding something new, they easily double check that the id they're inputting isn't already in the application somewhere. Or you can generate them programmatically to ensure this but then you lose readability in your tests sometimes.Feel free to DM me, I always love helping people with testing.
Bronkic@reddit
What do you need 150 tests for? I work at a company of similar size as yours and we have like 10 e2e tests. Just one for the important user flows, like registration or the main features. You don't need to test everything.
Flimsy_Hat_7326@reddit
playwright is as good as it gets for traditional frameworks tbh, if you want less maintenance you probably need to look at the ai powered options or just accept the tradeoff
virtuallynudebot@reddit
agreed, playwright is peak traditional automation, anything better is gonna be a different approach entirely
sallamx99@reddit
At one of the jobs I worked for, we started with all 3 levels of tests (unit, integration, e2e)
Overtime we found the e2e tests to be slow and brittle. We started ignoring them.
Overtime, we completely removed and we didn't have an increase in bug count.
The architecture did help a lot though.
We stripped down the UI framework (vue in this case) to just bind variables and event handlers that were free from framework code. We called them Presentation Models.
They are effectively a model of the screen without the HTML template.
Testing them was like testing any JS code in Jest or Mocha.
Of course we had a bug every now and then, but it was very fast to isolate and resolve.
If I was to do e2e testing again, I would pick a few critical paths to test upon deployment.
For example, a broken search box on an e-commerce website is terrible since that's your entrypoint. But a broken filter option is not the end of the world.
Much_Lingonberry2839@reddit
check out ai based tools, we switched from playwright to momentic specifically for this reason, the self healing caught most of our breaking changes automatically. still some manual work but way less
Brodor10@reddit
Have a look at the Page Object Model pattern, which might ease the pain a bit regarding changing locators. Extracting the locators and the behaviour around them into one of these caveman you only need to change one place if your locators change, rather than all the test files themselves.
virtuallynudebot@reddit
this is just the reality of e2e testing unfortunately, maintenance is always gonna be a thing
valbaca@reddit
I'm always preaching that UI tests should be kept as absolutely minimal and dumb-simple as possible because this is exactly what happens every single time
But no. Every team wants to raise the bar and "test everything" in the UI and then you end up exactly where you are: you're babysitting flaky or inconsistent tests more than you're working on the actual thing.
Logical-Idea-1708@reddit
Huh, are you using their fixture / page object pattern?
throwaway_0x90@reddit
The only problem Selenium has is that people constantly misuse it. Used properly, it's objectively the best.
Wonderful-Habit-139@reddit
Had to drop it due to lack of async support in Python. Sometimes it’s just not the right tool.
throwaway_0x90@reddit
Hmm...
Are you talking about this issue?
Wonderful-Habit-139@reddit
The first option mentioned is still running selenium in a synchronous way, the second option (using arsenic) hasn’t been maintained for over 3 years.
throwaway_0x90@reddit
This comment,
Seems acceptable to me. I see the reply about resources but in a test environment that's starting up browsers I'd like to think adequate resources are available on the host machine.
Wonderful-Habit-139@reddit
Yeah… it’s not as efficient but would still work, except for the fact that I needed to use an async queue in between selenium calls. And if I had to call multiple run_in_executor functions to still have access to the async queue in between then… that’s even more hacks.
But it is valid though, I can see how it would work for some. I actually even tried using janus to be able to communicate between sync and async functions but I ended up just using playwright with its async api, less headache and one less dependency.
throwaway_0x90@reddit
I'm curious to see the code. I'm imagining just small lambdas doing single selenium calls so you can go back to using the async queue afterwards, but depending on the complexity of the scenario I could see this getting cumbersome.
throwaway_0x90@reddit
Okay, but this the issue you're seeing?
You want to be able to do
await driver.get('https://reddit.com')?throwaway_0x90@reddit
I'm definitely curious what kind of web UI you're automating where this was an issue.
kyoob@reddit
I see this line of questioning with UI automation tools a lot. What do we expect? If you massively changed the business logic in the backend code, to the extent that the interface that “users”(in this case calling methods that refer to the changed code) have to use different signatures and call patterns to do the same thing, you’d expect to have to update your unit tests too. It’s the same. You’re changing how users make the app do its thing, and your tests are an automated representation of what your users will have to do. It’s part of change.
SignoreBanana@reddit
You should read up on "the testing pyramid"
Shookfr@reddit
IMO the testing landscape has evolved. UI testing used to be a lot harder and what was true when the pyramid concept was introduced doesn't really hold up anymore.
SignoreBanana@reddit
I respectfully disagree. It's become easier to write UI tests, but the same issues exist. Standard environment instability and complexity of modern UI will mean that you will continually run into the same kinds of problems: flaky tests eroding trust and a never ending game of whack a mole with your test suite.
Best to limit E2E testing maximally.
tetryds@reddit
This is not a playwright problem. This is also one of the reasons why a test automation engineer role exists. Every ui-changing task should be accompanied by a test updating one. In the end while being a lot of work, updating a few locators is less work than manually testing the whole thing over and over again, and automated tests pay off pretty quickly.
bigorangemachine@reddit
Ya or else you e2e become a kluge.
If someone is adding a random pop-up window they need to provide a way for the e2e tester to disable it.
TBH they need e2e tests part of the PR then... if people just 'throwing it over the fence' then OFC it's a difficult tool to maintain.
flavius-as@reddit
The biggest challenge you have is maturity in product thinking and systems thinking.
Once you get that down, thinking in terms of business goals and outcomes, writing your tests such that they secure just that becomes fairly easy.
DogOfTheBone@reddit
Might be a hot take but if your UI is shifting so much that you're spending more time fixing tests than writing feature work then your UI might not need E2E tests. Especially at an early stage startup.
Think about your users. How often are they logging in and finding the UI has changed? If it's as much as the post makes it seem then it's got to be incredibly frustrating.
Playwright isn't a tool that gives much value when you are in the figuring out what to build and what the UI stage looks like. It's a tool that gives lots of value when your core UI is relatively stable.
Look at what parts of your UI haven't changed much in 3 months (arbitrary time, longer would be better). Keep tests for those. Delete everything else. Then when a piece of UI has proved durable, add tests to it.
You are discovering that E2E UI tests are both incredibly brittle and incredibly heavy. In the right context those tradeoffs are worth it because they can be incredibly valuable. It sounds like this Series A startup is not the right context, and now you're burning tons of valuable dev time and investor money fucking around with a self-created problem instead of building cool shit and rapidly delivering business value.
lalaym_2309@reddit
Your maintenance pain is from relying on a big E2E net; shrink to a small smoke suite and push most checks to API/contract and component tests with a strict selector contract.
Lock selectors: keep all data-testid values in a single testIds file, fail PRs on removal/rename, and have page objects consume that map so you change one place. Add a codemod to update testIds when components get renamed; prefer ARIA roles/labels over CSS; disable animations, avoid hard waits, and stub third parties with route.fulfill.
Treat UI changes as versioned: feature-flag the new UI, run both test variants for a week, then switch; quarantine flaky tests. Use visual tests for layout-only changes (Percy or Chromatic) and delete E2Es that duplicate those checks. Stabilize data with a test-data API and ephemeral DBs per run (Testcontainers or snapshot restore).
Using GitHub Actions for CI and Percy for visual diffs, DreamFactory gave us a fast REST layer to seed/reset Postgres and Mongo so Playwright isn’t blocked by UI setup.
Keep E2E lean and enforce stable selectors; let lower-level tests carry the bulk so upkeep stays sane
Shookfr@reddit
On all of my projects we've come to the conclusion that e2e testing are too expensive.
If you have gafam money sure you can go over the top. But for the kind of work I do regression testing isn't worth. Usually proper types and mapping takes care of the heavy lifting.
turtlemaster09@reddit
Tthe idea that a series A sass product has e2e test ans is concused why they are not helpful is so sad. its like saying hey im a series a taco start up that is making tacos, i bought a food analyzer that i configured to test the salt fat and sugar content of my tacos ( set for optimal taste) .. when i change the recipe i have to reconfigure the machine.. why is that so hard....... dude you make tacos.. bite the fucking taco and see if it tastes good.. when you ship 500 billion tacos everyday, thenn you need the machine wtf its insaine.... log into your app test and use your app why are devs so afraid of that
Otherwise_Sign8964@reddit
Underrated comment. I’m not sure what OP is building, but typically for a series A startup, you are probably still trying to find PMF or has just reached MVP, but in any case your product is still rapidly evolving. E2E tests are famously brittle. The more you assert, the more frequently it breaks. It’s supposed to be used for testing workflows that absolutely should not ever break like the sign up and login flow. The fact that OP has 157 e2e tests seems to me all he’s using it to substitute every other kinds of tests. So what happens is when something deep inside the hierarchy breaks, a massively wall of stack trace and error shows up and just finding the actually origin of the error takes an hour. Compound that with a few more items and you’ve just used a whole day to fix a broken test.
I know there’s a myth that most tests should be e2e tests cos that saves you time blah blah blah. IMO, whoever uttered that nonsense has never stayed on a project longer than a few months.
Most of your tests should be unit tests. If any of them break, you can immediately identify which component breaks and fix accordingly. Once you have good coverage in that layer, then you can layer on top some integration tests to cover how some smaller subtrees of components interact. E2E tests should be the last resort. You should only reach for it if and only if there are critical paths that that you don’t want to mock the data layer. These paths should be quite rare.
Make your test pyramid actually look like a pyramid.
eggZeppelin@reddit
End-to-end tests will always suffer from being brittle
At a certain point, the false negatives and flapping tests outweigh the value provided
Its up to the team to decide how much to invest in that level of the testing pyramid
Zero219@reddit
0dev0100@reddit
How many refactors are you doing?
If you keep updating your UI as you described them your frontend or design probably is not ready for automated testing of this type.
It could also be that your tests need to reuse code that makes the page do things.
JollyJoker3@reddit
If you have the locator for a single field in more than one place, that would be bad. We have "page" files with keywords for navigating to a page and filling the forms on it or verifying the data, so on the calling end filling a page is just one line.
Agentic coding may be useful for updating tests too. Technically you have the info on what's changed in the code so an agent coud look at the commits of the front code and figure out what needs to change in the tests.
Another thing is having the same person who makes the change update the tests, if that's not already happening. That person knows exactly what has changed and why.
octatone@reddit
Shouldn’t be merging broken tests to main, simple as that. Whomever is doing refactors/adding features should be validating against your test suite before merging. This should be handled by CI. You fixing tests is the wrong approach here.
ElectricalMixerPot@reddit
Test breaks during feature dev... You still have to "fix" the test.
I don't think this guy is saying they're fixing broken CI... They're saying the overhead of maintaining tests during development is higher than the cost of developing X thing.
Ciff_@reddit
rcls0053@reddit
You need to offload that work to the developers who break the tests. That's all there is to it. This isn't a tool problem.
dpjorgen@reddit
I'm curious what your tests look like/how the code I structured. It's common to lose time to updating tests with UI redacties but not to the extent you mention here. I would also take a look at having 150 UI tests. Could be fine but there may be some room to remove or replace those tests with less brittle API tests. You may at least be able to replace some of the UI parts of the tests with API calls if you are doing similar actions like logging in or setting up data.
papawish@reddit
I'm not a frontend eng, but it seems perfectly reasonable to me that on such a platform (multi-browser, multi-cpu-arch, multi-OS, interpreted with user access to code, open to the world), tests represent 90% of your job.
I mean, that's if you want to prevent bugs and weird user behaviors with security implications.
Otherwise you can just accept a few bugs I guess, especially if you are in a company were the product that is pivoting/changing fast.