Feature flag testing

Checking the old and new code paths behind a feature flag, including rollout rules and the fallback when the flag service fails.

“test the feature both on and off”“make sure the old path still works”“test a hidden feature before rollout”“what happens when the flag changes”“feature toggle test”“feature flag testng”“test every flag state”“half our users see the new version and half do not”

What it is

Feature flag testing checks every supported path through a flag, not just the new path developers happen to have enabled locally. At minimum that means flag off and flag on. Targeted rollouts add more cases: eligible and ineligible users, percentage boundaries, a missing flag, and the provider being unavailable.

Put fast tests around the decision logic, integration tests around both code paths, and one end-to-end check around the released behavior that matters most. LaunchDarkly, Unleash, and similar SDKs accept a default value for a reason, so test that fallback explicitly.

Gotcha: two flags can produce four combinations, ten can produce 1,024. Do not brute-force every combination. Test each flag's states, then add pairwise or risk-based cases for flags that interact, and delete the tests with the flag when the rollout is complete.

Ask AI for it

Write Vitest coverage for this LaunchDarkly-backed feature flag. Inject the flag evaluator so tests can control `LDClient.variation`, then cover flag off, flag on, an eligible targeted user, an ineligible user, a missing flag, and an SDK error that returns the explicit default value. Add integration tests proving both old and new paths persist the correct result, plus one Playwright test for the enabled user journey. Do not mock the business logic behind either path.

You might have meant

feature flagunit testintegration testend to end testregression test