Feature Flags and Testing: Because QA Deserves Surprises Too

Feature flags solve a lot of deployment problems. They also create a whole new set of testing problems. Every flag introduces a branch in your code. Every branch needs to be tested. The math gets uncomfortable fast.

The State Explosion Problem

One feature flag means two states: On. Off.

Two flags means four states. Ten flags means 1,024 possible combinations.

You are not going to test all of them. Nobody is. But some of those combinations will behave unexpectedly, and your users will find them at the worst possible time. The practical approach is to identify which flag combinations actually matter for your application and test those specifically.

Flags that affect the same feature or code path are more likely to interact badly. Flags for completely independent features probably don't need to be tested together.

Test Every State of Every Flag

At a minimum, every flag should be tested in both its enabled and disabled states. This sounds obvious. It's also incredibly easy to forget. When adding a flag, developers tend to test the shiny new code path and forget to verify that the old path still works. Don't. Write explicit tests for both states:

[Fact]
public async Task Index_ReturnsNewDashboard_WhenFlagEnabled()
{
    // Arrange
    _featureManager
        .Setup(fm => fm.IsEnabledAsync("NewDashboard"))
        .ReturnsAsync(true);

    // Act
    var result = await _controller.Index();

    // Assert
    var viewResult = Assert.IsType<ViewResult>(result);
    Assert.Equal("NewDashboard", viewResult.ViewName);
}

[Fact]
public async Task Index_ReturnsOldDashboard_WhenFlagDisabled()
{
    // Arrange
    _featureManager
        .Setup(fm => fm.IsEnabledAsync("NewDashboard"))
        .ReturnsAsync(false);

    // Act
    var result = await _controller.Index();

    // Assert
    var viewResult = Assert.IsType<ViewResult>(result);
    Assert.Equal("OldDashboard", viewResult.ViewName);
}

Both tests matter. Don't skip the disabled case.

That's usually the code path everyone assumes will keep working forever.

Test the Flag Infrastructure

Here's another fun question: What happens when your flag service is unavailable?

Nobody's perfect. Your application should have a defined behavior when the flag infrastructure goes down. A safe default is usually to treat the flag as disabled. And yes, that behavior should be tested. "Works on my machine when the flag server is up" is not a test strategy.

Write tests that simulate a flag service outage and verify that your application degrades gracefully. Users shouldn't see an error because a configuration service had a brief hiccup. The important part is that you know what happens and you've tested it.

Automate Everything

Manual testing of feature flag states doesn't scale. Have ten active flags? Asking QA to manually verify both states of every flag before every release is a fantastic way to produce burnout, missed coverage, and possibly a strongly worded email.

Automate it. Your CI pipeline should run your flag-state tests automatically. Use mocks or test configuration to control flag values in your test suite.

Don't make your CI pipeline depend on a live flag server.

Your tests should be deterministic. Your production infrastructure can provide enough chaos on its own.

Document Expected Behavior

For every flag, document what the application should do when the flag is:

Enabled
Disabled

That documentation becomes the specification your tests enforce. Without documentation, "works on my machine" becomes the de facto specification. With documentation, everyone has a shared understanding of what correct behavior actually means. That makes it easier to: