Tests automatisés avec bascules de fonctionnalités

Les bascules de fonctionnalités sont utiles lors du développement de nouvelles fonctionnalités et de leur mise en production. Vous pouvez tester de nouvelles fonctionnalités en production mais les masquer aux utilisateurs finaux. Comment s'intègrent-ils dans votre plan de tests automatisés ?

Les bascules de fonctionnalités (également appelées commutateurs ou drapeaux) sont une méthode utile qui permet d'activer ou de désactiver des fonctionnalités sans avoir à modifier le code. Pour activer ou désactiver la fonctionnalité, il y aura généralement un paramètre dans un fichier de configuration qui permet d'activer ou de désactiver la fonctionnalité à tout moment. Cela permet à l'équipe de développement de tester la fonctionnalité avant sa sortie officielle.

Une alternative aux bascules de fonctionnalités serait d'avoir deux branches de code distinctes. Cela réduit la complexité, mais peut entraîner des problèmes lors de la fusion des deux branches. En incluant les deux ensembles de code dans une seule branche, nous réduisons considérablement le risque de conflits de fusion majeurs.

Un autre avantage des bascules de fonctionnalités est qu'elles permettent à la fonctionnalité d'être disponible uniquement pour certains utilisateurs. Par exemple, la fonctionnalité ne peut être activée que pour les utilisateurs appartenant à un canal ou à un groupe d'utilisateurs particulier. Cela permet à l'entreprise d'opter pour une version progressive où elle peut évaluer le comportement de l'utilisateur avant de décider si la fonctionnalité peut être publiée pour plus d'utilisateurs.

Comment fonctionnent les bascules de fonctionnalités ?

Le "commutateur" lui-même peut exister dans un fichier de configuration ou une base de données. Dans certains cas, une application d'interface utilisateur supplémentaire existe avec une liste de fonctionnalités et un "commutateur" à côté d'eux. Si le commutateur est en position "on", la fonction sera disponible dans l'application cible.

Le commutateur peut être utilisé pour masquer ou afficher une nouvelle fonctionnalité, ou remplacer une fonctionnalité existante par une nouvelle version.

Bascule de fonctionnalité qui active une nouvelle fonctionnalité

Lorsqu'une bascule de fonctionnalité active une nouvelle fonctionnalité, le code peut ressembler à ceci :

si (enableNewFeature)  
{  
  newFeatureCode()  
}

Si le commutateur de la nouvelle fonctionnalité est sur "on", alorsenableNewFeature sera défini sur vrai. La fonctionnouveauFeatureCode()sera exécuté et la nouvelle fonctionnalité sera disponible pour l'utilisateur.

Si le commutateur de fonction est "off", alorsenableNewFeatureest faux etnouveauFeatureCode() n'est pas exécuté. La fonctionnalité n'est pas mise à la disposition de l'utilisateur.

Bascules de fonctionnalité qui remplacent une fonctionnalité par une nouvelle fonctionnalité

Lorsqu'une bascule de fonctionnalité remplace une fonctionnalité existante par une nouvelle fonctionnalité, le code peut ressembler à ceci :

si (enableNewFeature)  
{  
  newFeatureCode()  
}autre  
{  
  oldFeatureCode()  
}

Si le commutateur de la nouvelle fonctionnalité est sur "on", alors la fonctionnouveauFeatureCode()est exécuté et la nouvelle fonctionnalité est mise à la disposition de l'utilisateur.

Si le commutateur de la nouvelle fonctionnalité est sur "off", la fonctionoldFeatureCode()est exécuté et la fonction d'origine est mise à la disposition de l'utilisateur à la place.

Ce que cela signifie pour les tests automatisés

Malheureusement, l'inclusion de bascules de fonctionnalités peut causer des problèmes pour les tests automatisés.

Développer des tests pour une fonctionnalité qui pourrait être activée ou désactivée à tout moment est un défi, car les tests échoueront si la bascule de fonctionnalité n'est pas dans le bon état.

Tests de nouvelles fonctionnalités contrôlées par des bascules de fonctionnalités

Une nouvelle fonctionnalité nécessitera de nouveaux tests, mais ces tests échoueront si la fonctionnalité est actuellement désactivée. Une solution simple consiste à supprimer ces tests du test principal jusqu'à ce que la fonctionnalité soit officiellement publiée. Jusque-là, n'exécutez les tests que lorsque cela est nécessaire et si la fonctionnalité a été activée. Une fois la fonctionnalité officiellement publiée, les tests peuvent être ajoutés au test principal.

Si vous le souhaitez, vous pouvez inclure un test qui s'assure que la fonctionnalité n'est pas disponible lorsqu'elle est désactivée. Cependant, cela pourrait être considéré comme excessif quand on sait que le test devra être supprimé une fois la fonctionnalité publiée.

Tests des fonctionnalités remplaçant les fonctionnalités existantes

Les tests automatisés pour ces fonctionnalités seront un peu plus compliqués et dépendront de plusieurs facteurs, notamment s'il existe des tests existants pour la fonctionnalité d'origine.

S'il n'existe aucun test automatisé (ce qui est courant pour les applications plus anciennes avec des fonctionnalités implémentées avant qu'une stratégie d'automatisation ne soit développée), vous traiterez la fonctionnalité comme s'il s'agissait d'une toute nouvelle. Créez simplement de nouveaux tests qui couvrent la nouvelle version de la fonctionnalité, ne les exécutez que lorsque la fonctionnalité est activée et ne les incluez dans le test principal qu'une fois la fonctionnalité entièrement publiée. Il est inutile de créer des tests pour la version originale de la fonctionnalité car celle-ci a désormais une durée de vie limitée.

Si des tests automatisés existent déjà pour la version d'origine de la fonctionnalité, ces tests devront être mis à jour car ils échoueront une fois la nouvelle fonctionnalité publiée et la fonctionnalité d'origine désactivée. Il existe deux options pour gérer cette situation :

1. Créez un ensemble de nouveaux tests, exécutez les anciens tests lorsque la fonctionnalité est désactivée et exécutez les nouveaux tests lorsque la fonctionnalité est activée.
2. Introduisez une autre fonctionnalité bascule dans un fichier de configuration qui définit si le nouveau paiement est activé ou non, et introduisezsiinstructions aux sections de code où un nouveau code est requis pour couvrir la nouvelle version de la caisse.

Voici les avantages et inconvénients de ces options :

Développer deux ensembles de tests pour les anciennes et les nouvelles fonctionnalités :

+ Moins de complexité de code car les nouveaux et anciens tests seront séparés.
+ Plus facile de supprimer les anciens tests une fois la nouvelle fonctionnalité publiée et le basculement de fonctionnalité n'est plus nécessaire.
– La maintenance des tests augmentera car les nouveaux et les anciens tests nécessiteront une maintenance.
– S'il y a beaucoup de tests à exécuter, choisir les bons tests à exécuter peut prêter à confusion.

L'introduction d'une fonctionnalité de test bascule afin que les tests existants contiennent des étapes pour la nouvelle et l'ancienne fonctionnalité :

+ Une seule série de tests devra être maintenue. Cela sera particulièrement bénéfique s'il existe des étapes partagées pour les anciennes et les nouvelles fonctionnalités.
+ Étant donné que les étapes de test sont contrôlées par un seul paramètre dans le fichier de configuration, il n'est pas nécessaire d'apporter des modifications à l'exécution réelle du test. Tout ce que le testeur doit faire est de s'assurer que le paramètre de configuration du test correspond au paramètre de basculement de la fonctionnalité.
– Présentations desiinstructions dans le code de test augmenteront la complexité du code car chaque test couvrira deux fonctionnalités différentes.
– Une fois que la nouvelle fonctionnalité a été publiée et que la bascule de fonctionnalité n'est plus nécessaire, tout le code couvrant l'ancienne fonctionnalité devra être supprimé. Cela devra être fait pour que le nouveau code de test ne soit pas accidentellement impacté par la suppression du code.

Éviter les dettes

Une erreur courante commise avec les bascules de fonctionnalités est que les équipes de développement oublient de les supprimer une fois la nouvelle fonctionnalité lancée. Le problème est que les entreprises aiment introduire une période de réflexion pendant laquelle elles s'assurent que la nouvelle fonctionnalité fonctionne et répond à son objectif. Avoir la possibilité de supprimer rapidement une fonctionnalité si elle ne fonctionne pas comme il se doit peut être rassurant.

Malheureusement, au moment où il est décidé qu'une bascule de fonctionnalité n'est plus nécessaire, l'équipe de développement est susceptible d'être passée à un nouveau projet. Par conséquent, la suppression des anciennes bascules de fonctionnalités devient moins prioritaire. Cela suppose qu'une décision de supprimer la bascule est prise. Parfois, la bascule est oubliée et reste dans l'application jusqu'à ce que l'application ne soit plus requise. Le problème ici est que cela peut entraîner la présence d'une grande quantité de code redondant dans le logiciel.

Si davantage de bascules de fonctionnalités sont introduites dans l'application, le suivi des bascules existantes et de celles qui sont activées peut devenir un véritable défi. Cela rend également les tests plus compliqués car les testeurs peuvent avoir à vérifier non seulement si une bascule de fonctionnalité fonctionne, mais également comment plusieurs paramètres de bascule de fonctionnalité fonctionnent ensemble (par exemple, la fonctionnalité A est activée, B est désactivée, C est désactivée, etc.) .

Il est essentiel de garder une trace des bascules de fonctionnalités existantes et d'être très strict pour s'assurer que les bascules de fonctionnalités et tout le code associé sont supprimés une fois que la bascule n'est plus nécessaire. La suppression des bascules de fonctionnalités peut créer des problèmes supplémentaires, et il est important non seulement de les supprimer, mais également de vérifier que la suppression de la bascule n'a pas eu d'impact sur les fonctionnalités existantes.

Sommaire

Les bascules de fonctionnalités sont un moyen utile de développer de nouvelles fonctionnalités et de les publier en production, tout en offrant la possibilité de les désactiver si nécessaire. Cela offre la possibilité de tester la nouvelle fonctionnalité en production mais en la gardant cachée aux utilisateurs finaux.

Les tests automatisés qui couvrent la nouvelle fonctionnalité ne doivent être exécutés que lorsque la nouvelle fonctionnalité a été activée. Les tests existants qui couvrent une ancienne version de la fonctionnalité peuvent être soit remplacés par de nouveaux tests, soit adaptés afin qu'ils puissent être exécutés sur la nouvelle fonctionnalité.

Une fois que la bascule de fonctionnalité n'est plus requise, la bascule de fonctionnalité et tout code lié à la bascule de fonctionnalité doivent être définitivement supprimés. Pour éviter une situation où il existe un grand nombre de bascules de fonctionnalités difficiles à suivre, il est essentiel que les bascules de fonctionnalités soient supprimées une fois que la fonctionnalité a été testée, publiée et confirmée comme étant adaptée à l'objectif.

Lectures complémentaires

Un article révélateur qui met en évidence les problèmes de basculement des fonctionnalités peut apporter plus de détails :

Quelques articles qui fournissent des détails sur les variations des bascules de fonctionnalités, des disjoncteurs et du modèle d'expérience scientifique :