ci
5 articles
-
Flaky Tests: Why Your Automation Flickers and How to Fix It
Green one run, red the next — with no code change. The 6 main causes of flaky tests, concrete fixes for each, and how to catch instability in CI. With a checklist.
-
Autotests that aren't in CI are a hobby: wiring tests into the pipeline without drowning
400 autotests that run "sometimes, locally" are not automation. A first-person take: run layers (a PR gate budgeted in minutes / post-merge / nightly), sharding and why parallelism kills dependent tests, a retry policy that doesn't mask flakiness (passed-on-retry = yellow, not green), quarantine with exactly two exits, the red-main rule, failure artifacts (a trace instead of re-debugging), and suite health metrics.
-
What to automate and what to leave manual — and why 'automate everything' kills the suite
'Automate everything' turns into a red suite nobody trusts within six months. A first-person take: the test we fixed for half a year when we should have deleted it; why an autotest costs not 'to write' but 'to maintain for years'; what's worth automating (stable, frequent, expensive by hand, deterministic) and what to leave to a human; the pyramid as a decision calculator; why a flaky test is worse than a missing one, plus an 'automate or not' checklist.
-
Test data in automated tests: a source of flakiness and coupling — and how to prepare it
Test data is one of the most invisible sources of flaky tests, bigger than locators. Isolation, determinism (freeze clock, seeded Faker), uniqueness under parallelism, factories vs fixtures vs API setup, cleanup and anonymizing prod data. A 12-point checklist.
-
Testcontainers: real databases, Kafka and Redis in tests instead of mocks and a shared environment
How to test integration against a real Postgres, Kafka and Redis in Docker — without lying mocks or a flaky shared environment. Wait strategies, reusable containers, Ryuk, modules, CI, and a 10-point adoption checklist.