Feature toggles (also known as switches or flags) allow certain features within an application to be added or removed with the flick of a switch. The feature can be activated or deactivated without having to change the code.
Imagine that you’re working on an application that includes a timetable feature. The team is working on a newer, more impressive timetable. Instead of completely removing the original timetable, the new timetable can be introduced and switched on when needed.
Here is what the code might look like:
if(useFancyTimeTable)
{
FancyTimeTable();
}
else
{
TimeTable();
}
To use the new ‘Fancy’ timetable, ‘useFancyTimeTable’ is set to true. It’s as simple as that!
The feature could be switched on via a config file setting or an internal application which includes switches for other features. Someone working for the business can switch the feature on or off as required.
Some applications may allow the user to try out new features that have not yet been fully released. The user can switch on a feature using a switch available somewhere within the application. The user gets to try out new features, and the business gets some initial real-world feedback about how well the new feature is behaving.
The advantage of features toggles is that the new feature can be released to production, but not made immediately available. The new feature is switched on at a suitable and convenient time that will not significantly impact the business or user.
What does Feature Toggles mean for Testing?
When testing the new feature with a feature toggle, the toggle needs to be tested as well as the feature itself. The feature should only be visible to the end-user when it has been switched on.
If the new feature is replacing an older version, then both need to be tested in case a change has affected either version. If the feature isn’t planned to be switched on immediately, then the old feature still needs to continue to work reliably.
If the application already has a set of automated tests designed to run with the original feature, then these will need to be updated so they work with the new one. However, it’s worth keeping the original tests until the feature has been completely removed.
When storing the automated test scripts in source control, keep two separate branches – one to run with the tests for the original feature, and another containing the tests for the new feature. This will allow both sets of automated tests to be run when required, ensuring that the application works as expected when the feature has been enabled and disabled.
All automated tests should also be backed up with exploratory testing of both the new and original feature.
Alternatives To Feature Toggles
Phased Releases
Instead of releasing to all users at once, it might be considered less risky to release to only a small number of users first. The business might decide to only switch the features on for a small percentage of users, 10% say.
If any unexpected issues occur, then only a small number of users will be impacted. Once confidence with the new feature has grown, the percentage is gradually increased until it is made available to all users.
If testing an application that uses phased releases, the feature should be set to appear to 100% of users on the environment that the tests are being run on. Otherwise, some tests will fail because some are being run with the feature switched on and others with the feature switched off.
Circuit Breakers
A circuit breaker is tipped if a fault is detected, protecting the circuit from further damage. When the fault has been detected and fixed, the circuit breaker is reset and normal operations resume.
The theory behind this can be applied in a similar way to feature toggles. A feature is switched on, but if an error is detected then the circuit breaker is tripped. The user is still able to use the original feature with no further issues.
Once the fault is detected, fixed and tested, then the feature can be enabled again.
Science Experiments
There are now two versions of the same feature. Why not test both?
For a period of time, the original feature continues to be used while the code for the new feature runs in the background. The results from both the old and new feature are compared to check for discrepancies. This means any bugs that are found in the new feature will not impact the user. Once all bugs have been identified, the new feature can finally be switched on.
Further Reading
Feature Toggles – https://martinfowler.com/articles/feature-toggles.html
Circuit Breakers – https://martinfowler.com/bliki/CircuitBreaker.html
More on Circuit Breakers & science experiment model – https://www.ministryoftesting.com/dojo/lessons/testing-in-production-the-mad-science-way?s_id=27125