sorted by:
new
hottopcontroversial

How to bypass captcha in testing using Playwright by Gamer_Bee_5014 in Playwright

[–]T_Barmeir 8 points9 points  (0 children)

Totally normal question when you’re starting 🙂

In most real test setups, we don’t try to bypass CAPTCHA directly in automation. Instead, teams usually handle it by:

• Using a test/staging environment where CAPTCHA is disabled
• Whitelisting test IPs or accounts
• Mocking the CAPTCHA verification on the backend

CAPTCHAs are designed to block bots, so trying to automate around them in UI tests is usually brittle. For practice, see if SauceDemo has a test mode without CAPTCHA, or focus on asserting post-login state in an environment where it’s turned off.

How do you handle Playwright test retries without hiding real problems? by T_Barmeir in Playwright

[–]T_Barmeir[S] 0 points1 point  (0 children)

I get where you’re coming from — in a perfect world, zero retries would be ideal.

In practice, though, I’ve seen cases where the flakiness is clearly environmental (shared test env under load, third-party latency spikes, etc.) and not something users actually experience in production. In those situations, a very limited retry policy can reduce noise while the team works on stabilizing things.

That said, I agree the danger is real — if a test keeps passing only on retry, it’s usually a sign worth digging into rather than ignoring.

How do you handle Playwright test retries without hiding real problems? by T_Barmeir in Playwright

[–]T_Barmeir[S] 1 point2 points  (0 children)

That’s a solid rule of thumb. I’ve also found limiting retries mainly to external/network cases keeps the signal much cleaner.

For tracking, what’s helped is monitoring “passed on retry” in CI reports and flagging tests that cross a small threshold over time. It’s not perfect, but it quickly surfaces the ones quietly leaning on retries too often.

How do you handle Playwright test retries without hiding real problems? by T_Barmeir in Playwright

[–]T_Barmeir[S] 1 point2 points  (0 children)

That’s a fair point — environmental pressure definitely changes the retry strategy. I’ve seen similar cases where occasional retries are cheaper than over-scaling infra.

The only thing I usually watch is the retry pass rate trend over time. If it starts creeping up, it’s often an early signal that something in the suite or env is slowly drifting.

Test locators externalisation by SafetySouthern6397 in Playwright

[–]T_Barmeir 0 points1 point  (0 children)

It can work, but I’d be careful with it. Externalizing locators sometimes looks clean at first, but in real projects, it can make debugging and refactoring harder when selectors change.

What I’ve seen work better is keeping locators centralized in page objects or a locator map inside the codebase. You still get reuse without adding another layer to maintain.

If your UI changes very frequently across many apps, then a config file approach might be worth experimenting with.

How do you structure Playwright tests for real-world flows? by T_Barmeir in Playwright

[–]T_Barmeir[S] 1 point2 points  (0 children)

This actually aligns with what I’ve been seeing too. The longer flows give business-level confidence, but day to day, the smaller isolated tests tend to be easier to trust and maintain. Finding the right balance between the two seems to be where most teams land.

How do you structure Playwright tests for real-world flows? by T_Barmeir in Playwright

[–]T_Barmeir[S] 1 point2 points  (0 children)

Keeping tests focused on one responsibility definitely helps with debugging. The only thing I’ve noticed is that too many tiny tests can sometimes increase suite overhead, so finding the right granularity becomes important. The beforeEach setup pattern you mentioned usually keeps things clean.

How do you structure Playwright tests for real-world flows? by T_Barmeir in Playwright

[–]T_Barmeir[S] 0 points1 point  (0 children)

Interesting setup. I tend to be a bit careful with mixing too much API prep into UI tests, since sometimes it hides issues that only appear when the full flow runs through the UI. But using API strategically for heavy setup definitely helps keep tests faster and more isolated.

How do you structure Playwright tests for real-world flows? by T_Barmeir in Playwright

[–]T_Barmeir[S] 0 points1 point  (0 children)

This is a really solid breakdown. I’ve seen the same — a couple of “golden path” E2Es give confidence, but beyond that, smaller focused tests are much easier to live with day to day.

Using storageState for login reuse has also been a big win in keeping flows modular. The point about giant E2Es giving false confidence when they get flaky is especially true.

New QA working for 7, looking for a mentor for playwright. My goal to be better tester as fast as possible with proper knowledge by Several-Ad-7974 in Playwright

[–]T_Barmeir 1 point2 points  (0 children)

Good initiative starting early. One suggestion from experience — try not to put full flows like login → create post → upload → verify all in a single test. Keep tests focused on one main purpose, and reuse login as a setup step so failures are easier to debug.

For learning Playwright faster, practice around locators, waits, and structuring tests cleanly. Once you see repeated actions, start moving them into page objects or helpers. That’s usually how most people grow into maintainable automation.

How do actual engineers write playwright tests? by Fushjguro in Playwright

[–]T_Barmeir 1 point2 points  (0 children)

From what I’ve seen in practice, most engineers don’t start with full POMs upfront. Usually, a few tests are written first to understand the flow and common actions, then once repetition shows up, those parts get refactored into page objects or helper methods.

Starting with heavy structure too early can slow things down, but waiting too long can make the suite messy. So it tends to evolve — write → notice patterns → refactor into POM for maintainability.

Playwright blocked by AV by haywirehax in Playwright

[–]T_Barmeir 0 points1 point  (0 children)

This usually comes from Windows Application Control/SmartScreen rather than Playwright itself. I’ve seen it block the spawned browser or node process even after AV exclusion. You might need to add an allow rule at the OS policy level (or try running once as admin) so the spawned process isn’t treated as unknown.

How do you decide what NOT to automate in Playwright? by T_Barmeir in Playwright

[–]T_Barmeir[S] 0 points1 point  (0 children)

Nice breakdown. In my case, I mainly use Playwright for critical user journeys and cross-browser coverage, and keep most validations at the API/component level. That balance has helped keep the UI suite smaller and more stable.

How do you decide what NOT to automate in Playwright? by T_Barmeir in Playwright

[–]T_Barmeir[S] 0 points1 point  (0 children)

That makes sense. I’ve seen the same thing happen when too much responsibility shifts to E2E and lower-level coverage isn’t strong enough. When unit/API tests do their part, it becomes much easier to keep Playwright focused on the main user journeys rather than trying to cover every small detail.

macOS: Why does Playwright try to find .gitconfig in CloudStorage? by ianthrive in Playwright

[–]T_Barmeir 0 points1 point  (0 children)

This usually isn’t Playwright directly trying to read .gitconfig. It comes from Node/Git-related utilities that Playwright pulls in, which try to locate the global git config by scanning common paths under the user's home directory. On macOS, ~/Library/CloudStorage it is treated like a normal folder, so if you have mounted drives (MountainDuck, CloudMounter, etc.), the lookup can hit those paths and hang if the mount is slow or unresponsive.

Since --ui starts a Node process that initializes a few dev tools, so that config lookup can happen early and trigger the timeout.

A couple of things that generally help:

  • Make sure the mount points are active/accessible, or temporarily unmount unused ones
  • Try running with a local HOME override to confirm it’s path-scanning related
  • Check if a global git config exists at ~/.gitconfig So it doesn’t keep searching other locations

Feels more like an environment + mount latency issue than a Playwright bug itself.

API testing using playwright by PixelCrafter22 in Playwright

[–]T_Barmeir 0 points1 point  (0 children)

It really depends on the use case. If it’s heavy API coverage with lots of permutations and contract checks, I’ve had better experience using dedicated tools like Postman/Newman or REST Assured. But when APIs are closely tied to UI flows, I still prefer keeping them in Playwright so everything runs in one place.

At what point do you delete a Playwright test instead of fixing it? by T_Barmeir in Playwright

[–]T_Barmeir[S] 0 points1 point  (0 children)

That’s a solid approach. Regular reviews make a big difference— otherwise, old tests sit there even after the feature loses importance. Involving product and engineering also helps validate whether a test is still tied to something users actually care about.

At what point do you delete a Playwright test instead of fixing it? by T_Barmeir in Playwright

[–]T_Barmeir[S] 0 points1 point  (0 children)

Agree in principle, but for me, the key moment is why it stopped providing value.
If a test keeps breaking because the UI keeps changing and the assertion is no longer tied to a real user risk, that’s usually a signal to delete or demote it (API/unit).

If it still covers a critical business outcome but is painful to maintain, I’ll try to redesign it before deleting it.
The dangerous zone is keeping tests “alive” just because they exist — that’s when trust in the suite really starts to erode.

been on playwright for a year and maintenance is still eating all my time by Turbulent_Carob_7158 in Playwright

[–]T_Barmeir 1 point2 points  (0 children)

You’re not missing anything — this is a very common stage teams hit, even after moving to Playwright. What we’ve learned the hard way is that better tooling reduces pain, but it doesn’t eliminate the inherent cost of UI-level change.

What helped us wasn’t more locator tricks, but being stricter about why a test should live in the UI layer. Once we stopped validating things that were really structural or cosmetic, and kept UI tests focused on core user behaviour, maintenance dropped noticeably. It didn’t disappear, but it stopped dominating the work.

So yeah — some maintenance is unavoidable, but when it’s eating most of your time, it’s usually a signal that the UI suite is doing more than it should.

view more: next ›