Développement de machines à états avec développement piloté par les tests

Étant donné que les modèles de machines à états sont largement utilisés dans les systèmes embarqués, cet article explore plusieurs stratégies pour développer des logiciels de machines à états (SM) dans le cadre de l'approche de développement piloté par les tests (TDD). Cette publication commence par expliquer les concepts de base des machines à états et la technique TDD. Enfin, il présente des méthodes simples et ordonnées pour développer un logiciel de machine à états écrit en C en utilisant l'approche TDD.

Un modèle SM est composé d'états, de transitions et d'actions. Alors qu'un état est une condition d'un système ou d'un élément, une transition est un chemin d'un état à un autre, généralement initié par un événement d'intérêt qui relie un état prédécesseur (source) à un état (cible) suivant. Les comportements réels exécutés par l'élément sont représentés dans des actions.

Dans la machine à états UML, les actions peuvent être associées à l'entrée dans un état, à la sortie d'un état, à une transition en soi, ou à ce qu'on appelle une « transition interne » ou une « réaction ». Tous les formalismes de la machine à états (y compris les machines à états UML) supposent universellement qu'une machine à états termine le traitement de chaque événement avant de pouvoir commencer à traiter le suivant. Ce modèle d'exécution est appelé Run To Completion (RTC). Dans ce modèle, les actions peuvent prendre du temps, mais tous les événements en attente doivent attendre la fin de la machine d'état, y compris l'intégralité de l'action de sortie, l'action de transition et la séquence d'action d'entrée dans cet ordre.

Avant d'aborder les stratégies pour développer des machines à états en utilisant TDD, il convient de mentionner sa définition, son importance et son application.

Tout d'abord, TDD est une technique de construction incrémentale de logiciels. En termes simples, aucun code de production n'est écrit sans avoir d'abord écrit un test unitaire défaillant. Les tests sont petits. Les tests sont automatisés. Le test de conduite est logique, c'est-à-dire qu'au lieu de plonger dans le code de production (en laissant les tests pour plus tard), le praticien TDD exprime le comportement souhaité du code dans un test. Une fois que le test échoue, le praticien TDD écrit le code, faisant passer le test. Au cœur du processus TDD, il existe un cycle répétitif composé de courtes étapes appelées « microcycles TDD ».

Les étapes du cycle TDD dans la liste suivante sont basées sur le livre "Test-Driven Development for Embedded C" de James Grenning :

• Ajoutez un petit test.
• Exécutez tous les tests et si le nouveau échoue, il peut même ne pas être compilé.
• Apportez les petites modifications nécessaires pour réussir le test.
• Exécutez tous les tests et prouvez si le nouveau réussit.
• Refactorisation pour supprimer les doublons et améliorer l'expressivité.

Utilisons le diagramme de la figure 1 pour trouver un moyen plus simple de développer une machine à états à l'aide de TDD. Lorsque la machine d'état est initialisée, elle démarre à partir du StateA Etat. Une fois qu'il reçoit l'Alpha événement, la machine à états passe à l'StateB state en exécutant les actions xStateA(), effect() et nStateB() dans cet ordre. Alors, comment peut-on tester le SM de la figure 1 pour déterminer s'il se comporte correctement ?

Figure 1. Machine à états de base (Source :VortexMakes)

La manière la plus traditionnelle et la plus simple de tester un SM comme la figure 1 consiste principalement à vérifier la table de transition d'état du SMUT (State Machine Under Test). Cela fait un cas de test par état , dans lequel le SMUT est stimulé par les événements d'intérêt pour vérifier quelles transitions sont déclenchées. Dans le même temps, cela impliquera de vérifier l'état de la cible et les actions exécutées pour chaque transition déclenchée. Si une action est suffisamment complexe, il est plus approprié de faire un cas de test spécifique pour cela. (L'article Tester les machines d'état à l'aide de tests unitaires explique cette stratégie en détail).

Chaque cas de test est divisé en quatre phases distinctes selon des modèles xUnit :

• Configuration établit les conditions préalables du test, telles que l'état actuel du SM (StateA ), l'événement à traiter (Alpha ) et les résultats de test attendus, qui sont l'état cible de transition (StateB ) et la liste triée des actions à exécuter (xStateA(), effect() et nStateB()).
• Exercice stimule la machine à états avec l'Alpha événement.
• Vérifier vérifie les résultats obtenus.
• Nettoyage renvoie la machine d'état testée à son état initial après le test. C'est facultatif.

La stratégie mentionnée ci-dessus est suffisante pour développer un SM utilisant TDD. Cependant, dans certains cas, plusieurs transitions sont nécessaires pour vérifier la fonctionnalité. En effet, l'effet n'est visible qu'en raison d'une chaîne d'actions de transitions ultérieures, ce qui signifie que la fonctionnalité implique un ensemble d'états, d'événements et de transitions du SMUT. Dans ces cas, il est plus approprié de tester un scénario complet et fonctionnel que des transitions d'état isolées. En conséquence, les cas de test sont plus fonctionnels et moins abstraits que les stratégies mentionnées précédemment.

Utilisons la machine à états de la figure 2 pour explorer ce concept.

Figure 2. La machine à états DoWhile (Source :VortexMakes)

La figure 2 montre une machine à états appelée DoWhile, qui modélise une boucle d'exécution similaire à celle de « do-while ». DoWhile a été dessiné à l'aide de Yakindu Statechart Tool. Les actions « x =0 » et « output =0 » sont appelées lorsque DoWhile est créé et ces actions définissent la valeur par défaut de tous les attributs de DoWhile. Le nombre d'itérations de boucle doit être défini par « x++ » ou « x =(x> 0) ? x– :x’ actions. L'action « i =0 » établit les conditions initiales pour la boucle. Le corps de la boucle est exécuté par l'action « i++ », qui maintient les itérations de la boucle, puis la condition de terminaison est évaluée par le pseudo-état de choix via la garde « i ==x ». Si c'est vrai, le corps de la boucle est à nouveau évalué, et ainsi de suite. Lorsque la condition de terminaison devient fausse, la boucle se termine en exécutant l'action 'output =i'.

Il est utile de créer une liste de tests avant de développer de nouvelles fonctionnalités. La liste des tests découle du cahier des charges et définit la meilleure vision de ce qu'il doit être fait. Puisqu'elle n'a pas besoin d'être parfaite, l'ancienne liste n'est qu'un document temporaire qui pourra être modifié par la suite. La liste de tests initiale pour DoWhile est présentée ci-dessous :

• Toutes les données sont définies par défaut après l'initialisation de SM
• Incrémenter l'attribut X
• Décrémenter l'attribut X
• Une seule boucle d'itération peut être exécutée
• Une boucle d'itérations multiples peut être exécutée
• Une boucle sans itération peut être exécutée
• Vérifier les valeurs hors limites

Afin de développer la machine à états DoWhile, Ceedling et Unity seront utilisés avec la technique de programmation la plus simple mais la plus lucide :l'utilisation de phrases « switch-case ». Ceedling est un système de build permettant de générer un environnement de test et de build complet pour un projet C; Unity est un harnais de test de langage C expressif portable et léger pour les projets C.

Deux fichiers représentent cette machine d'état, DoWhile.h et DoWhile.c, ils constituent donc le code source testé. La liste de code 1 montre un fragment du fichier test_DoWhile.c, qui implémente la liste de tests ci-dessus en appliquant la stratégie mentionnée précédemment. Afin de garder cet article simple, la liste de code 1 ne montre que le cas de test : « Une seule boucle d'itération peut être exécutée », qui est implémenté par test_SingleIteration(). Le code et le modèle sont disponibles dans le référentiel https://github.com/leanfrancucci/sm-tdd.git.

Liste de code 1 :test d'itération unique (Source :VortexMakes)

Ce test vérifie que DoWhile peut exécuter correctement une seule itération. Pour ce faire, test_SingleIteration() initialise la machine à états DoWhile en appelant DoWhile_init() (ligne 96). Il définit le numéro d'itération pour zéro à exécuter par la boucle DoWhile. Après cela, le DoWhile est prêt à traiter les événements en appelant DoWhile_dispatch(). Pour exécuter une seule itération, test_SingleIteration() envoie le Up événement à DoWhile (ligne 97). Cet événement incrémente le numéro d'itération à un. Le test démarre la boucle en envoyant le Start événement (ligne 98), puis il envoie le Alpha événement afin que DoWhile exécute une seule itération (ligne 99). Ceci est vérifié en vérifiant que la valeur de l'attribut out est égale au nombre d'itérations exécutées (ligne 101). Enfin, DoWhile doit rester dans le StateC état (ligne 102).

Pour prouver que DoWhile peut exécuter plus d'une itération, test_SingleIteration() est étendu comme indiqué dans la liste de code 2.

Liste de code 2 :test d'itérations multiples (Source :VortexMakes)

Le test test_NoneIteration() montré dans la liste de code 3 vérifie que DoWhile n'exécute aucune itération lors de la réception d'un Alpha événement sans définir au préalable le numéro d'itération via Up événements.

Liste de code 3 :test sans itération (Source :VortexMakes)

Bien que les détails de l'implémentation de DoWhile ne soient pas l'objectif de cet article, la liste de code 4 et la liste de code 5 montrent une partie des fichiers DoWhile.c et DoWhile.h. Ces fichiers représentent en fait une implémentation démonstrative de DoWhile utilisant des phrases « switch-case » en C.

Liste de code 4 :Fragment de l'implémentation de DoWhile (Source :VortexMakes)

Liste de code 5 : fragment de la spécification DoWhile (Source :VortexMakes)

Les deux stratégies présentées ci-dessus fournissent des méthodes simples et ordonnées pour développer un logiciel de machine d'état à l'aide de TDD - l'une des approches les plus importantes pour augmenter la qualité du logiciel.

La première stratégie consiste principalement à vérifier la table de transition d'état du SMUT. Cette méthode crée un cas de test par état . L'autre stratégie propose de réaliser un cas test pour un scénario complet et fonctionnel , qui implique fréquemment un ensemble d'états, d'événements et d'actions du SMUT. Cette seconde stratégie rend le test plus fonctionnel et moins abstrait que la première. Bien que ces stratégies soient indépendantes d'un type particulier de système, de langage de programmation ou d'outil, elles sont très utiles dans les systèmes embarqués, car nombre d'entre elles ont un comportement basé sur l'état qui est généralement défini dans une ou plusieurs machines à états.

Le langage C a été choisi car il est l'un des langages les plus populaires pour le développement de logiciels embarqués. Ainsi, afin d'appliquer TDD dans cette langue, Ceedling et Unity ont été choisis. Pour conclure, ces méthodes permettent certainement aux développeurs de construire de manière plus simple et ordonnée un logiciel beaucoup plus flexible, maintenable et réutilisable que les approches traditionnelles.