E2E: UI에 대한 과도한 결합 방지

Source: Dev.to

While there are fantastic e2e frameworks, such as Playwright, tools cannot prevent misuses.

Implementation details vs. behaviors

A very common mistake is focusing on implementation details:

await page.goto('/signup');
await expect(page.locator('.btn-signup.primary')).toBeVisible();

It’s not necessarily bad in all cases, but it couples the test to frontend styling decisions. Any CSS refactor or restructure will cause test failures unrelated to functionality.

Instead, focus on the feature:

await page.goto('/signup');
/* there might be other tests here, like filling some inputs */
await page.click('#submit-signup');

Nested elements vs. resilient tests

Relying on a deep CSS selector is usually not ideal:

await page.locator(
  '#tsf > div:nth-child(2) > div.A8SBwf > div.RNNXgb > div > div.a4bIc > input'
).click();

Source: Locate by CSS or XPath - Playwright

Playwright provides an extensive API, but that doesn’t mean you should use fragile selectors. CSS and XPath are not recommended because the DOM can change, leading to non‑resilient tests. Prefer locators that reflect how a user perceives the page, such as role locators or explicit test IDs.

Lack of fixtures

Creating everything through slow UI interactions makes e2e tests very slow. Reusable fixtures ensure consistency and prevent repeated setup logic:

// ./tests/fixtures/myFixture.js
const test = baseTest.extend(/* your code */);

// ./tests/pages/mypage.spec.js
import { test } from '../fixtures/myFixture';

test('should do something good', async ({ target }) => {
  /* your code */
});

Source: Fixtures - Playwright

Defensive over‑testing

You’ll likely have unit tests (pure business logic), integration tests, and other layers before your e2e tests. E2e tests should focus on the real user experience, not re‑assess everything covered by lower‑level tests. Ensure the layers are complementary, not redundant, to avoid duplicated effort, slower automation, and higher costs.

How to do better

Avoid the bad practices described above and follow good design principles:

• Create fresh data for each test run.
• Don’t assume previous results; keep tests independent.
• Split long tests into smaller, focused tests.
• Test only what the user sees (e.g., a success message, not a CSS class).

Writing maintainable tests may take more time upfront, but the cost of brittle e2e tests can be significant.