การเขียนการทดสอบ E2E ที่เชื่อถือได้: กำจัดความไม่แน่นอน

End-to-end tests touch the whole system, so they are the most prone to flakiness: passing one run and failing the next with no code change. Flaky tests erode trust in the whole suite.

The most common cause is timing. The test checks the UI or response before the system finished processing, due to network or async work.

A hard-coded sleep is fragile: too short and it fails, too long and the suite crawls.

Instead, wait for a condition. The test proceeds as soon as the expected state appears, up to a timeout.

Tests that share data can interfere when order or parallelism changes. Each test must set up and clean up its own data.

Generate unique data per test, such as a random email, so concurrent runs never collide.

Third-party services and unstable test environments add noise. Pin versions, use dedicated test instances, and stub volatile externals where appropriate.

UI tests break when selectors target styling. Use dedicated test identifiers instead of brittle CSS paths.

Automatic retries can mask real bugs, so use them sparingly and only after addressing root causes. Always log retried failures so flakiness stays visible.

When a test turns flaky, quarantine it from the gating suite, file a ticket, and fix the root cause rather than deleting or ignoring it permanently.

A trustworthy E2E suite gives genuine release confidence; a flaky one gets ignored and provides none.

What is the preferred fix for timing-related flakiness?

You learned to fight flakiness:

• Replace fixed sleeps with explicit condition waits
• Isolate data with unique values per test
• Use stable test selectors, not styling paths
• Quarantine and fix flaky tests instead of ignoring them