Forem: TestDino

Mistake 12/14: You're not catching visual regressions

TestDino — Thu, 16 Apr 2026 13:22:33 +0000

A simple CSS change broke the checkout button on mobile. Every functional test passed.

The scary part? Nobody knew. The button was technically in the DOM. It had the correct text. But to an actual user, it was completely invisible, overlapped by a rogue div on mobile screens only. The kind of bug that gets caught in production when a customer tries to check out and can't.

Functional tests are great for verifying behavior. They are not designed to check appearance. They can't tell you if your app actually looks right.

BEFORE : Functional test passes. Button is covered on mobile.

// ❌ BEFORE — Functional test passes, but the button is covered on mobile.
await expect(page.getByRole('button', { name: 'Checkout' })).toBeVisible();
// Passes because the button is in the DOM, even if users can't actually click it.

AFTER : Visual regression catches layout issues across devices.

// ✅ AFTER — Visual regression catches layout issues across devices.
test('cart page looks correct', async ({ page }) => {
  await page.goto('/cart');

  await expect(page).toHaveScreenshot('cart.png', {
    mask: [
      page.getByTestId('timestamp'),   // changes every run
      page.getByTestId('order-id'),    // unique per session
    ],
    maxDiffPixelRatio: 0.01,
  });
});

// 🧪 Test across viewports in playwright.config.ts
{ name: 'desktop', use: { viewport: { width: 1280, height: 720 } } },
{ name: 'mobile',  use: { viewport: { width: 375, height: 667 } } },

Playwright's built-in visual comparisons (toHaveScreenshot) catch these layout breaks instantly. The quick pro-tip that saves every team time: always mask dynamic elements like timestamps or order IDs to avoid flaky false positives.

The distinction most teams miss is this: functional tests verify that something works. Visual tests verify that users can actually see and interact with it. Both questions matter. Most suites only answer one of them.

When you add visual coverage at the viewport level, you stop shipping layout bugs that your test suite is structurally incapable of catching.

Have visual tests ever caught a bug your functional tests completely missed? Drop it in the comments.

Mistake 11/14: Your E2E tests are checking email format

TestDino — Wed, 15 Apr 2026 13:46:00 +0000

if you are running 400 E2E tests and half of them validate form inputs like email format, you are burning browser time on logic that never needed a browser.

The inconsistency isn't obvious at first. These tests pass. They feel useful. But every one of them navigates to a login page, authenticates, clicks through menus, waits for redirects. All to verify that a regex rejects "not-an-email". That is 30 seconds of browser overhead for a check that has nothing to do with the browser.

BEFORE - E2E for email validation. 30 seconds of overhead.

// Every spec file repeats this flow
test('rejects invalid email', async ({ page }) => {
  await page.goto('/login');                          // navigate
  await page.getByLabel('Email').fill('not-an-email');// fill
  await page.getByRole('button', { name: 'Sign in' }).click();
  await expect(page.getByText('Invalid email')).toBeVisible(); // 30 sec for this
});

AFTER - Component test. Same assertion. 200ms

import { test } from '@playwright/experimental-ct-react';
import { LoginForm } from '../src/components/LoginForm';

test('rejects invalid email', async ({ mount }) => {
  const form = await mount(<LoginForm />);            // no navigation. no login.
  await form.getByLabel('Email').fill('not-an-email');
  await form.getByRole('button', { name: 'Sign in' }).click();
  await expect(form.getByText('Invalid email')).toBeVisible();
});

The distinction most teams miss is this: E2E tests exist to cover what only E2E can cover. Multi-page flows, payment processing, cross-service coordination. That is the territory.

Form validation, input constraints, UI state changes. Those belong at the component level.

When you separate them, everything gets faster and each layer actually earns its place. ⚡

What percentage of your E2E tests are actually testing component behavior? Drop it in the comments.

Playwright Mistake 10/14: Flaky Tests Are Not Random

TestDino — Tue, 14 Apr 2026 13:50:10 +0000

You re-run. It passes. You move on.

Until your whole team is trained to ignore failures. That's when real bugs slip through.

Here are the 3 root causes behind 90% of flaky Playwright tests.

Race Condition

// bad
const text = await page.locator('.welcome').textContent();

// good
await expect(page.getByText('Welcome back')).toBeVisible();
// auto-retries until element exists

Shared Data

// bad
await request.delete('/api/users/test-user-1');
// 5 workers fight over this

// good
const user = await createUniqueUser(request);
await request.delete(`/api/users/${user.id}`);
// each test gets its own

Network Timing

// bad
await page.goto('/search?q=laptop');
await page.locator('.result').first().click();
// results not loaded yet

// good
await page.goto('/search?q=laptop');
await page.waitForResponse('**/api/search');
await page.getByTestId('result').first().click();

Which of these three has burned you the most on your current project?

Mistake 9/14: Stop Relying on Staging Data for Edge Case Testing

TestDino — Mon, 13 Apr 2026 13:04:11 +0000

You finish the happy path tests. Coverage looks solid. Then a user reports the error screen is broken. You never caught it because your suite never actually triggered a server error.

Most teams skip edge cases entirely , or spend hours crafting corrupted data in staging just to trigger one scenario. Then the data gets cleaned up, and the test breaks again.

This is the exact pattern that makes test suites unreliable as they grow.

Playwright's page.route() removes the backend dependency completely. You return whatever response you want : empty arrays, server errors, malformed JSON, slow responses; directly from the test. Your staging environment stays untouched.

The Clean Pattern

Instead of relying on staging state, intercept the network call and return exactly what you need to test:

// Test 1: Empty state
test('shows empty state when no users found', async ({ page }) => {
  await page.route('/api/users', route =>
    route.fulfill({
      status: 200,
      contentType: 'application/json',
      body: JSON.stringify([]),
    })
  );
  await page.goto('/users');
  await expect(page.getByText('No users found')).toBeVisible();
});

Then handle the failure and timeout cases the same way:

// Test 2: Server error
test('shows error message on server failure', async ({ page }) => {
  await page.route('/api/users', route =>
    route.fulfill({
      status: 500,
      body: JSON.stringify({ error: 'Internal Server Error' }),
    })
  );
  await page.goto('/users');
  await expect(page.getByText('Something went wrong')).toBeVisible();
  await expect(page.getByRole('button', { name: 'Retry' })).toBeVisible();
});

// Test 3: Slow response
test('shows loading spinner and timeout message', async ({ page }) => {
  await page.route('/api/users', async route => {
    await new Promise(resolve => setTimeout(resolve, 10000));
    await route.fulfill({ status: 200, body: '[]' });
  });
  await page.goto('/users');
  await expect(page.getByTestId('loading-spinner')).toBeVisible();
  await expect(page.getByText('Request timed out')).toBeVisible({ timeout: 15000 });
});

Zero backend involvement: No staging data setup or cleanup needed
Fully deterministic: The test controls exactly what the API returns
Three edge cases covered: Empty state, server error, and timeout , all in one go

Empty states, error screens, and timeout messages are exactly what users see when things go wrong. Those paths deserve real test coverage, not a "we'll check it manually" comment in the PR.

Do you enforce API mocking for edge cases on your team, or is it still a free-for-all?

Drop it in the comments.

Playwright Mistake 8/14: You Only Check Status Codes on API Responses

TestDino — Sat, 11 Apr 2026 12:36:05 +0000

The docs said the field was a string. Production returned null. Your test passed because you only asserted status === 200.

That's the problem.

What actually happened

The frontend called .toUpperCase() on null. Page crashed. Your test had no idea.

Checking the status code and calling it tested is like confirming the door is closed without checking if it's locked.

These two error messages tell the whole story

"Expected string, received null at 'name'" → 2-minute fix
"Cannot read properties of undefined"      → 2-hour debug

One catches the issue at test time. The other catches it in production.

The fix: validate the response shape

// BEFORE
test('get user profile', async ({ request }) => {
  const response = await request.get('/api/users/123');
  await response.json();
  expect(response.status()).toBe(200);
  // Backend returns { name: null }. Test passes. Frontend breaks.
});

// AFTER
import { z } from 'zod';

const UserSchema = z.object({
  id:        z.string().uuid(),
  name:      z.string(),
  email:     z.string().email(),
  role:      z.enum(['admin', 'member']),
  createdAt: z.string().datetime(),
});

test('get user profile - validate contract', async ({ request }) => {
  const response = await request.get('/api/users/123');
  expect(response.status()).toBe(200);

  const body   = await response.json();
  const result = UserSchema.safeParse(body);

  // name null?       Caught here.
  // field removed?   Caught here.
  // type changed?    Caught here.
  expect(result.success).toBe(true);
});

Why it matters at scale

One method: safeParse covers every field in one call
Visible failure: tells you exactly which field broke and why
No prod surprises: field renames, null returns, type changes all fail at test time

When you have 200+ API tests only checking status codes, you have 200+ tests that can pass while the app is broken.

Tag someone who's still only asserting status codes.

Mistake 7/14: You are still using beforeEach for everything

TestDino — Fri, 10 Apr 2026 13:36:25 +0000

If you are still copy-pasting beforeEachblocks across fifty spec files to initialize your Page Objects, you are building a maintenance trap.

The inconsistency isn't laziness. It is what happens when your setup has no enforced contract across the codebase.

BEFORE - Brittle boilerplate

// Every spec file repeats this logic
let settingsPage;

test.beforeEach(async ({ page }) => {
  settingsPage = new SettingsPage(page);
});

AFTER - Scalable dependency injection

// fixtures.ts
export const test = base.extend({
  settingsPage: async ({ page }, use) => {
    await use(new SettingsPage(page));
  },
});

Playwright built Fixtures to eliminate the "which pattern did we agree on?" conversation.

-Encapsulation: Setup and teardown live together in the fixture.

-Lazy Loading: If a test doesn't ask for the fixture, it never runs.

-Consistency: One source of truth for every Page Object in your framework.

Stop managing state manually. Let the runner do the heavy lifting. ⚡

Do you enforce a fixture strategy on your team, or is it a free-for-all? Drop it in the comments.

Mistake 6/14: Stop Putting Assertions in Page Objects

TestDino — Thu, 09 Apr 2026 13:29:08 +0000

A developer wants to keep their tests "dry," so they put the expect statement inside the Page Object method. It makes sense at first. login() handles everything: fill the form, click the button, confirm you’re on the dashboard. One method. Clean. ✅

Until you need to test a failed login. ✖️

Now your login() method asserts success but your negative test is looking for a failure. To fix it, you add loginExpectingFailure(). Then loginAndCheckError(). Six login methods later, your POM is a graveyard of duplicated logic.

This is the exact trap teams fall into when a suite grows.

Page Objects should be simple. They store locators and perform actions. That is it. Assertions belong in the test file, where the intent of the test is immediately visible.

The Clean Pattern

Instead of baking the assertion into the class, keep the class "pure":

class LoginPage {
  async login(user, pass) {
    await this.emailInput.fill(user);
    await this.passInput.fill(pass);
    await this.submitBtn.click();
  }
}

Then, handle the different outcomes in your actual test files:

// Happy path
test('success', async ({ page, loginPage }) => {
  await loginPage.login('user@test.com', 'pass123');
  await expect(page).toHaveURL('/dashboard');
});

// Negative path
test('failure', async ({ page, loginPage }) => {
  await loginPage.login('user@test.com', 'wrong');
  await expect(loginPage.error).toBeVisible();
});

One method: A single login() method with zero assertions.
Visible Intent: Anyone reading the test knows exactly what is being verified.
No Bloat: No duplicated methods. No boolean flags. No loginVersion4().

Do you enforce a "no assertions in POM" rule on your team, or is it a free-for-all? Drop it in the comments.

playwright #testing #automation #sdet

Mistake 5/14: Your Tests Are Unreadable in the Report

TestDino — Wed, 08 Apr 2026 13:29:19 +0000

A test fails in CI. You open the Playwright HTML report and see 60 lines of code in one giant block. It says "line 47 timed out." You have no idea what the test was actually trying to do. You are left staring at a stack trace guessing which part of the flow broke.

The damage isn't just time. It's clarity. When test results are a pain to decipher, developers stop reading them. Failures get dismissed.

test.step() fixes this.

BEFORE: One giant block. The report just says "X test failed."

test('submit contact form', async ({ page }) => {
  await page.goto('/contact');
  await page.getByLabel('Name').fill('Jane');
  await page.getByLabel('Email').fill('jane@test.com');
  await page.getByRole('button', { name: 'Submit' }).click();
  await expect(page.getByText('Thank you')).toBeVisible();
});

AFTER: Named steps. The report reads like a story.

test('submit contact form', async ({ page }) => {
  await test.step('GIVEN user is on contact page', async () => {
    await page.goto('/contact');
  });

  await test.step('WHEN user fills and submits form', async () => {
    await page.getByLabel('Name').fill('Jane');
    await page.getByLabel('Email').fill('jane@test.com');
    await page.getByRole('button', { name: 'Submit' }).click();
  });

  await test.step('THEN success message appears', async () => {
    await expect(page.getByText('Thank you')).toBeVisible();
  });
});

The rule: Wrap your code in named steps using GIVEN, WHEN, and THEN.

Now your report says "WHEN user fills and submits form failed" instead of "line 47 timed out".

You know exactly what broke instantly. Debugging goes from minutes to seconds.

Do you use test.step() to structure your tests, or is your code one giant block? Drop it in the comments.

Mistake 4/14: Same data breaks Playwright group tests

TestDino — Tue, 07 Apr 2026 13:32:30 +0000

Running tests together? Same "test@test.com" makes workers fight over one user. Quiet fails everywhere. I reviewed a test suite last week where hardcoded data completely killed their pipeline stability. Worker 1 passes, Workers 2-5 throw "email already exists."

BEFORE : Tests fight each other

test('register new user', async ({ page }) => {
  await page.getByLabel('Email').fill('test@test.com'); 
  // Worker 1: passes. Workers 2-5: fail instantly
});

AFTER : The Factory + JSON Combo

Keep your hacks and limits in a static JSON file. Use a Faker factory for everything else. Zero collisions!

import { faker } from '@faker-js/faker';
import invalidInputs from './invalid-inputs.json';

// 1. Factory function for dynamic, unique runs
export function createTestUser() {
  return {
    email: `test-${Date.now()}-${faker.string.alphanumeric(5)}@test.com`,
    password: faker.internet.password({ length: 12 })
  };
}

test('happy path: zero collisions', async ({ page }) => {
  const user = createTestUser();
  await page.getByLabel('Email').fill(user.email);
  await page.getByLabel('Password').fill(user.password);
});

// 2. Static JSON data for deterministic edge cases
test('reject sql injection in name field', async ({ page }) => {
  // invalidInputs.sqlInjection[0] = "' OR 1=1 --"
  await page.getByLabel('Name').fill(invalidInputs.sqlInjection[0]);
  await expect(page.getByText('Invalid input')).toBeVisible(); 
});

Fixed data for hacks. Faker for everything else.

What's your test data strategy? Comments below.

Mistake 3/14: You Run Every Test on Every PR

TestDino — Mon, 06 Apr 2026 13:08:16 +0000

A developer pushes a button color change. CI triggers. Your full suite runs, including the complete checkout flow, destructive state tests, and edge cases that have nothing to do with the change. 45 minutes later, green check. Merge. Nobody questioned it.

The damage isn't just time. It's trust. Developers start ignoring CI results when feedback takes 45 minutes on a two-line change. Flaky failures get dismissed.Real failures get missed.

Test tagging fixes this.

BEFORE: No tags. Everything runs on every trigger.

test('add to cart', async ({ page }) => { /* ... */ });
test('complete purchase', async ({ page }) => { /* ... */ });
test('request refund', async ({ page }) => { /* ... */ });

AFTER: Tagged. Filtered by when and where they should run.

test('add to cart', { tag: '@smoke' }, async ({ page }) => { /* ... */ });
test('complete purchase', { tag: '@regression' }, async ({ page }) => { /* ... */ });
test('request refund', { tag: '@destructive' }, async ({ page }) => { /* ... */ });

// PR pipeline:   npx playwright test --grep @smoke        → 4 min
// Nightly:       npx playwright test --grep @regression   → 45 min
// Isolated:      npx playwright test --grep @destructive  → runs alone

@smoke: 20-30 critical tests. Every PR. Under 5 minutes. @regression: Full suite. Nightly. Catches everything without blocking anyone. @destructive: Modifies shared state. Isolated run. Doesn't pollute other results.

45 minutes down to 4. No infrastructure changes. Just tags.

Do you enforce a tagging strategy on your team, or is it a free-for-all? Drop it in the comments.

Mistake 2/14: Your locators will break on the next deploy

TestDino — Fri, 03 Apr 2026 12:26:59 +0000

Your locators are tied to exact DOM structure. A developer adds one wrapper div and your entire pipeline bleeds red.

We reviewed a suite last week. First thing we saw: page.locator('//div[@class="login-container"]/div[2]/form/button').

BEFORE - Brittle CSS = broken pipeline

await page.locator('form-group input#email-field').fill('user@test');
await page.locator('/div[@class="login-form"]').fill('user@test');
await page.locator('/div[2]/form/button').click();
await page.locator('form-group.btn-primary.submit-btn').click();

AFTER - Resilient, tied to what users see, not DOM structure

await page.getByLabel('Email').fill('user@test');
await page.getByLabel('Password').fill('pass');
await page.getByRole('button', { name: 'Sign in' }).click();

Playwright built accessibility locators to fix this. getByRole, getByLabel, getByText.

Priority: getByRole → getByLabel → getByText → getByTestId → CSS (last resort).

Do you enforce a locator strategy on your team, or is it a free-for-all? Drop it in the comments.

14 Playwright Mistakes Slowing Your Team Down : A Daily Series

TestDino — Thu, 02 Apr 2026 12:15:04 +0000

1 You are logging in through the UI in every single test.

Open the app. Type the email. Type the password. Click login. Wait for the redirect.

Now multiply that by 200 tests. That is 200 login screens that have nothing to do with what you are actually testing.

We audited a suite last month. 38% of total test runtime was spent on the login page. Not on testing features. On typing credentials into a form.

The fix is simple. Log in once via API, save the session, and every test loads that file and starts already authenticated.

// BEFORE - Every test logs in through the UI
test('check dashboard stats', async ({ page }) => {
  await page.goto('/login');
  await page.getByLabel('Email').fill('admin@company.com');
  await page.getByLabel('Password').fill('password123');
  await page.getByRole('button', { name: 'Sign in' }).click();
  await page.waitForURL('/dashboard');
  await expect(page.getByTestId('stats-panel')).toBeVisible();
});

// AFTER - Login once, reuse session across all tests

// auth.setup.ts
setup('authenticate', async ({ request }) => {
  await request.post('/api/auth/login', {
    data: { email: 'admin@company.com', password: 'password123' },
  });
  await request.storageState({ path: '.auth/admin.json' });
});

// playwright.config.ts
projects: [
  { name: 'auth-setup', testMatch: 'auth.setup.ts' },
  { name: 'chromium', use: { storageState: '.auth/admin.json' },
    dependencies: ['auth-setup'] },
]

// your test - starts already logged in
test('check dashboard stats', async ({ page }) => {
  await page.goto('/dashboard');
  await expect(page.getByTestId('stats-panel')).toBeVisible();
});

Your tests begin exactly where the user lands after login. The login screen never appears in your results again.

How does your team handle auth? UI login every time or something smarter?

Drop it in the comments.