Exécutez des tests unitaires localement dans STM32CubeIDE sous Windows

Présentation

Tout le monde connaît les avantages des tests unitaires. Tout d'abord, l'écriture de tests en même temps que le code vous permet de détecter les erreurs plus tôt et de ne pas perdre de temps par la suite sur un débogage complexe et long. Dans le cas du développement embarqué, les tests unitaires ont des fonctionnalités liées, d'une part, au fait que le code se trouve quelque part profondément dans les entrailles de l'appareil et qu'il est assez difficile d'interagir avec lui, et d'autre part, le code est fortement lié au matériel cible .

S'il y a des fragments dans le projet qui ne dépendent pas du matériel et implémentent en même temps une logique assez complexe, pour eux, l'utilisation de tests unitaires sera la plus avantageuse. Par exemple, il peut s'agir de la mise en œuvre d'un protocole de transfert de données, de divers calculs ou d'une machine à états de contrôle.

Il existe trois façons d'exécuter des tests unitaires pour les plates-formes intégrées:

1. Lancer directement sur la plateforme cible. Dans ce cas, vous pouvez travailler avec l'équipement de l'appareil et le code fonctionnera exactement de la même manière que dans les conditions de combat. Cependant, pour les tests, vous aurez besoin d'un accès physique à l'appareil. De plus, le cycle de test sera assez long en raison de la nécessité de télécharger constamment du code sur l'appareil.
2. Fonctionnant sur un émulateur. Cette méthode est bonne principalement parce qu'elle vous permet de travailler même lorsque la plate-forme cible n'est pas disponible (par exemple, car elle n'a pas encore été effectuée). Les inconvénients sont la précision limitée dans la reproduction du comportement du fer (et du monde environnant), ainsi que la difficulté de créer un tel émulateur.
3. En cours d'exécution sur la machine hôte (localement). Cela ne fonctionnera pas avec l'équipement (vous pouvez utiliser des talons de test à la place), mais les tests démarreront rapidement et fonctionneront, et vous n'avez pas besoin d'accéder au périphérique cible. Un bon exemple d'utilisation de cette méthode consiste à tester la mise en œuvre sur un microcontrôleur d'un algorithme de calcul, qui en soi ne dépend pas du matériel, mais utilise les données du capteur de l'appareil. Tester un algorithme avec une vraie source de données sera très gênant, il est préférable d'enregistrer une fois ces mesures et d'exécuter des tests déjà sur les données stockées. Ce script exécutera des tests localement et sera discuté plus tard.

Cette publication fournit un moyen de configurer les tests unitaires dans l'environnement STM32CubeIDE, basés sur Eclipse et destinés au développement des contrôleurs de la famille STM32. Le langage de développement est C, mais les tests eux-mêmes sont écrits en C ++. Les tests s'exécuteront sur une machine hôte Windows utilisant Cygwin. En tant que cadre de test, Google Test est utilisé. Les résultats seront affichés dans une fenêtre de plug-in spéciale pour les tests unitaires, et ils peuvent être lancés avec un bouton du projet pour STM32:

La méthode décrite convient à d'autres environnements de développement basés sur Eclipse, à moins bien sûr que les bons fabricants les aient trop coupés pour le confort des développeurs. Cette méthode fonctionnera également avec CubeIDE sous Linux, sans avoir à se soucier de Cygwin.

Vous aurez besoin

1. Cygwin 3.0.7 x86 (puisque les tests concernent un microcontrôleur 32 bits, nous utiliserons également un environnement 32 bits sur une plate-forme 64 bits)
2. STM32CubeIDE 1.0.2 pour Windows.
3. Google Test Framework 1.8.1

Installer Cygwin et STM32CubeIDE

Cygwin

Installez Cygwin, version x86. Dans le programme d'installation, sélectionnez des packages supplémentaires: gcc-core, g ++, binutils, automake, autoconf, cmake, libtool, gdb, make. Vous pouvez installer les dernières versions stables des packages.

Vous devez également enregistrer les variables d'environnement:

CHEMIN: ...; C: \ <path_to_Cygwin> \ Cygwin \ bin; C: \ <path_to_Cygwin> \ Cygwin \ lib
chemin de classe : C: \ <path_to_Cygwin> \ Cygwin \ lib

STM32CubeIDE

L'environnement est installé comme d'habitude. Il est conseillé d'installer CubeIDE après Cygwin, car dans ce cas, Cube récupérera la chaîne d'outils Cygwin existante.

Tout d'abord, créez un projet C ++ pour la plate-forme Cygwin x86. Nous en aurons besoin pour, d'une part, vérifier la fonctionnalité de la chaîne d'outils, et d'autre part, nous l'utiliserons comme «donneur» de la configuration d'assemblage du projet principal.

Choisissez Fichier> Nouveau> Projet C / C ++. Sélectionnez C ++ Managed Build. Nous créons un projet de type hello world pour la chaîne d'outils Cygwin GCC:

Ensuite, vous devrez choisir les configurations d'assemblage à créer. Un simple débogage suffit.
Vous pouvez maintenant vérifier que le projet se déroule en choisissant Projet> Tout construire. Il est également conseillé de vérifier le débogage sous Cygwin en exécutant Exécuter> Déboguer en tant que> Application C / C ++ locale. L'application affichera «Hello world» sur la console à l'intérieur de CubeIDE.

Pour que le débogueur affiche les lignes exécutables dans les fichiers de code source, vous devez configurer l'affichage des chemins. Dans la fenêtre Window> Preferences, dans l'onglet C / C ++> Debug, sélectionnez Source Lookup Path et ajoutez un nouvel affichage: Add> Path Mapping. Dans la fenêtre, vous devez nommer quelque chose comme un nouvel affichage et ajouter des lignes pour les disques qui sont dans le système:

• \ cygdrive \ c - C: \
• \ cygdrive \ g - G: \

Pour une belle exécution de test, nous avons également besoin d'un plug-in pour Eclipse avec prise en charge des tests unitaires pour C ++. Il est installé directement à partir de STM32CubeIDE: menu Aide> Installer un nouveau logiciel, puis sélectionnez le référentiel Eclipse et installez le plug-in C / C ++ Unit Testing Support.

Créer la bibliothèque de tests Google

Le code source de la bibliothèque peut être récupéré à: https://github.com/google/googletest/tree/release-1.8.1
Décompressez les sources, accédez au répertoire googletest-release-1.8.1 à l'aide du terminal Cygwin et exécutez:

cmake . make 

Une fois l'assemblage réussi, le fichier de bibliothèque statique sera dans ./googlemock/lib/libgtest.a et les fichiers d'en-tête seront dans le répertoire ./googletest/include/gtest/. Ils devront être copiés dans notre projet (ou pour enregistrer le chemin d'accès à ces fichiers dans les paramètres du projet).

Création d'un projet pour STM32

Conception pour la carte de débogage STM32L476G-DISCO. L'exemple ne sera pas trop sophistiqué - il y a deux LED sur la carte, laissez-les afficher un compteur binaire de 00 à 11. Nous allons implémenter un module séparé pour le compteur, décrit dans une paire de fichiers .h et .c, et écrire un test pour cela.
Le projet peut être créé comme d'habitude, en utilisant le configurateur Cube, l'essentiel est de s'assurer que les broches PB2 et PE8 sont configurées comme sorties numériques. Lors de la création d'un projet, il serait préférable de spécifier le type - C ++, cela sera nécessaire pour compiler les tests (le code principal sera toujours compilé par le compilateur C). La conversion d'un projet à partir de C sera possible plus tard, en cliquant sur le nom du projet RMB et en sélectionnant «Convertir en C ++».

Pour la compilation sous MK et pour les tests, nous avons besoin de deux configurations d'assemblage différentes. Dans ces configurations, différents ensembles de fichiers seront collectés - les principaux obtiendront les modules pour travailler avec le matériel et les modules testés, et le test obtiendra les mêmes modules testés et les mêmes fichiers de test. Par conséquent, nous créerons différents répertoires à la racine du projet - Application avec le code d'application pour MK (vous pouvez simplement renommer le répertoire Src créé par Cube), Commun pour les modules qui ne dépendent pas du fer (que nous testerons) et Tests pour les tests. Les répertoires peuvent être exclus de l'assembly en cliquant sur RMB sur leur nom, menu Configuration des ressources> Exclure de la génération.

Ajoutez notre module compteur au répertoire commun:

 #ifndef LED_COUNTER_H_ #define LED_COUNTER_H_ #include <stdint.h> void Led_Counter_Init(); uint8_t Led_Counter_Get_Next(); #endif /* LED_COUNTER_H_ */ 

 #include "led_counter.h" static uint8_t led_cnt_state = 0; void Led_Counter_Init() { led_cnt_state = 0; } uint8_t Led_Counter_Get_Next() { if(++led_cnt_state > 3) led_cnt_state = 0; return led_cnt_state; } 

Les répertoires Common et Tests doivent être ajoutés au chemin de recherche pour les fichiers include: propriétés du projet (Propriétés)> C / C ++ Général> Chemins et symboles> Inclut.

Ajouter au travail avec les LED principales

 … /* USER CODE BEGIN Includes */ #include "led_counter.h" /* USER CODE END Includes */ … int main(void) { … /* USER CODE BEGIN WHILE */ Led_Counter_Init(); uint8_t led_state = 0; while (1) { /* USER CODE END WHILE */ /* USER CODE BEGIN 3 */ led_state = Led_Counter_Get_Next(); HAL_GPIO_WritePin(GPIOB, GPIO_PIN_2, led_state & (1<<0)); HAL_GPIO_WritePin(GPIOE, GPIO_PIN_8, led_state & (1<<1)); HAL_Delay(500); } /* USER CODE END 3 */ … } 

Le projet doit être compilé et exécuté, et les voyants doivent clignoter.

Tests d'écriture

Maintenant ce pour quoi tout a commencé.

Créez une nouvelle configuration de construction via les propriétés du projet - Propriétés> Construction C / C ++> Paramètres> Gérer les configurations. CubeIDE ne vous permet tout simplement pas de créer une configuration pour la construction sous Cygwin, alors copiez-la à partir du projet que nous avons créé précédemment:

Vous devez maintenant basculer vers cette configuration et configurer les chemins d'accès aux fichiers source et aux fichiers d'en-tête. Dans les propriétés du projet dans l'onglet Chemins et symboles que nous prescrivons (lors de l'ajout d'une entrée, il est préférable de mettre un daw dans le champ "ajouter à toutes les langues"):

• Comprend - Tests / Inc, Commun / Inc
• Bibliothèques - gtest
• Chemins de bibliothèque - Tests / Lib
• Emplacement source - / <prj_name> / Common et / <prj_name> / Tests (remplacez <prj_name> par le nom du projet)

Ensuite, copiez la bibliothèque gtest - le fichier .a dans le répertoire Tests / Lib du projet et les fichiers d'en-tête dans le dossier gtest - dans le dossier Tests / Inc. Dans le dossier Tests, créez un nouveau fichier main.cpp dans lequel les tests seront exécutés. Son contenu est standard:

main.cpp:

 /* * Unit tests main file */ #include "gtest/gtest.h" int main(int argc, char *argv[]) { ::testing::InitGoogleTest(&argc, argv); return RUN_ALL_TESTS(); } 

De plus, pour vérifier la configuration, nous allons créer un test qui vérifiera que la taille du pointeur est de 32 bits dans notre environnement (nous voulons nous assurer qu'il est le même que sur le microcontrôleur, pour cela nous avons défini Cygwin 32 bits).

Créez le fichier de test test_platform.cpp suivant:

 #include "gtest/gtest.h" TEST(PlatformTest, TestPointerSize) { //Check pointer size is 32 bit ASSERT_EQ(sizeof(void*)*8, 32U); } 

Maintenant, si le projet est exécuté en tant qu'application C ++ normale, la sortie de débogage affichera un message de Google Test indiquant que tous les tests ont réussi.

La structure du projet devrait ressembler à ceci:

Nous allons maintenant écrire des tests pour notre module compteur LED. Les fichiers de test se trouvent dans le dossier Tests:

 #include "gtest/gtest.h" extern "C" { #include "led_counter.h" } // Test fixture class LedCounterTest: public ::testing::Test { protected: void SetUp() { Led_Counter_Init(); } }; // Check initial value TEST_F(LedCounterTest, TestInitialValue) { Led_Counter_Init(); ASSERT_EQ(Led_Counter_Get_Next(), 1); } // Check how value is incremented TEST_F(LedCounterTest, TestIncrementValue) { Led_Counter_Init(); unsigned int val = Led_Counter_Get_Next(); for(int i=0;i<1;i++) { ASSERT_EQ(Led_Counter_Get_Next(), ++val); } } // Check how value return to 0 after 3 TEST_F(LedCounterTest, TestZeroCrossing) { Led_Counter_Init(); for(int i=0;i<3;i++) { Led_Counter_Get_Next(); } ASSERT_EQ(Led_Counter_Get_Next(), 0); } 

Pour que les résultats du test soient affichés dans une belle fenêtre, vous devez créer une nouvelle configuration de lancement dans le menu Exécuter> Configurations de débogage. Le plugin installé vous permet de créer des configurations de type C / C ++ Unit. Créez-le, appelez Exécuter les tests, sélectionnez la configuration utilisée de l'assemblage «Test» et décochez la case «Arrêter au démarrage à» de l'onglet Débogueur. Après cela, la configuration peut être lancée.

Pour qu'une fenêtre avec les résultats apparaisse, sélectionnez-la dans Fenêtre> Afficher la vue> Autre> C / C ++> Unité C / C ++.

C'est fait! Maintenant, le projet peut être compilé et exécuté sous le MK cible comme d'habitude. Lorsque vous devez exécuter des tests locaux, lorsque vous exécutez la configuration Exécuter les tests, le projet est automatiquement reconstruit pour x86, l'environnement exécute les tests et affiche le résultat.

Littérature

1. J. Grenning. Développement piloté par les tests pour Embedded C. - travaux fondamentaux sur les tests unitaires des systèmes embarqués et sur l'application de la méthodologie TDD.
2. https://uncannier.com/unit-testing-of-embedded-firmware-part-1-software-confucius/ - Test unitaire du code du microcontrôleur x86 au Texas Compments Studio Code Composer Studio, framework CppUTest
3. http://blog.atollic.com/why-running-your-embedded-arm-cortex-code-on-a-host-pc-is-a-good-thing - un article expliquant pourquoi il pourrait être utile d'exécuter du code pour un microcontrôleur sur une plateforme de bureau