Feature flags for integrations: convenient in production, painful in tests
In PDP and PDP Mobile, external integrations can be disabled via config at a fine-grained level — for individual buildings and residential complexes. But that flexibility comes at the cost of combinatorial test complexity.
In PDP and PDP Mobile, we made it so that external integrations — CRM, 1C, address validation, access control systems, bank acquiring — can be turned off via config. Not globally, but selectively: at the level of individual buildings and residential complexes. In practice, feature flags control access to functionality where it is actually needed.
Sounds great: less hardcoding, more flexibility, faster rollout of changes. But there’s a catch, and it’s the classic one for 2025, when everyone loves configurability: combinatorial test complexity.
Each on/off combination for CRM, 1C, the address service, access control, and acquiring is already a separate scenario. So “let’s just check the flags” quickly turns into a quest-level problem of “why is the payment there, but the pass was never issued?”
We ran into the fact that an optional integration is not “optional for QA.” It’s architectural flexibility that you pay for with a matrix of scenarios.