Quel cadre de test unitaire puis-je utiliser pour un projet MCU basé sur AC?

Je réfléchis à la façon dont je peux utiliser les tests unitaires dans mon projet mcu et aux cadres que je peux utiliser pour le simplifier.

Aujourd'hui, j'utilise un stm32 avec OpenOCD-jtag à partir d'un PC Linux, où tout est contrôlé à partir d'un Makefile classique et compilé de manière croisée avec gcc.

Je pourrais créer quelque chose moi-même, mais s'il y a un cadre que je peux utiliser, ce serait bien. (C'est un bonus si le framework peut produire le résultat dans un format que Jenkins / Hudson peut lire).

Existe-t-il un moyen d'utiliser un framework de test unitaire avec un stm32?

Découvrez CppUTest et l'excellent http://pragprog.com/book/jgade/test-driven-development-for-embedded-c de James Grenning

CppUTest prend en charge C et C ++, et il dispose d'un bel ensemble de modèles Makefile qui m'a permis de démarrer assez rapidement.

Il existe de nombreuses variables qui détermineront le meilleur cadre de tests unitaires à utiliser dans votre situation. Certains éléments pouvant affecter votre choix seront:

• La langue cible.
• Quel support de bibliothèque est disponible. par exemple libc ou une version réduite de celle-ci.
• Le système d'exploitation de la cible. par exemple Aucun, FreeRTOS, personnalisé.

La plupart des frameworks de type xUnit fourniront un niveau de fonctionnalité de base qui peut être utile. J'ai utilisé Cunit avec un certain succès dans le passé. (paquet libcunit1-dev sur Ubuntu / Debian). La plupart des frameworks nécessiteront que libc soit disponible, certains nécessiteront un support supplémentaire du système d'exploitation.

Une autre alternative qui ne fait que 3 lignes est Minunit .

J'ai trouvé que les tests unitaires utilisant le microcontrôleur comme cible étaient assez lourds car vous devez être en mesure de présenter un environnement adapté pour télécharger des tests, les exécuter et ensuite obtenir des résultats. La simple mise en place de la plate-forme qui vous permettra de le faire est une grosse tâche.

Une autre approche que j'ai adoptée et qui a fonctionné pour moi est de faire des tests unitaires sur l'hôte, en implémentant une couche d'abstraction entre les pilotes et le code d'application. Puisque vous utilisez gcc pour la cible, le code doit également être compilé sur l'hôte.

Les tests sur l'hôte de compilation sont généralement beaucoup plus faciles car vous disposez de la prise en charge complète du système d'exploitation hôte et de tous ses outils. Par exemple, lors des tests sur l'hôte, j'ai une version simulée de mon pilote sans fil avec la même interface que le vrai pilote qui s'exécute sur la cible. La version hôte utilise des paquets UDP pour simuler le transfert de paquets sans fil, le pilote factice prenant en charge la possibilité de supprimer des paquets afin que je puisse tester mes protocoles.

Dans le produit sur lequel je travaillais, un OS fileté était utilisé, donc la couche d'abstraction pour tester sur l'OS hôte utilisait pthreads à la place.

Bien qu'il ne soit pas parfait, plus il vous est facile d'écrire et d'exécuter des tests, plus vous avez de chances d'implémenter plus de cas de test. Un autre avantage de l'exécution du code sur différentes plates-formes est de tester que le code est portable. Vous détecterez rapidement les erreurs endiennes si les architectures cible et hôte diffèrent.

Je suis maintenant un peu hors sujet, mais je pense que ces idées peuvent vous aider dans votre choix de cadre de test et de méthodes de test.

Consultez embUnit http://embunit.sourceforge.net/embunit/index.html . Il s'agit d'un cadre de test unitaire C intégré avec une faible empreinte.

Nous l'avons utilisé avec succès dans quelques projets de microcontrôleurs intégrés. Ne vous attendez pas aux options et fonctionnalités que vous obtenez avec un framework de test d'unité de bureau. Mais c'est définitivement assez puissant.

Il a un lot d'assertions défini pour vous, vous n'avez donc pas à perdre du temps à écrire des assertions personnalisées comme avec minUnit.

Il y a quelque temps, j'ai écrit un didacticiel complet sur le sujet: test C (embarqué) d'applications C avec Ceedling ; J'utilise ces techniques dans un tas de projets, et je suis assez content jusqu'à présent.

Je regardais juste cela moi-même. J'ai trouvé un article en trois parties qui décrit un cadre de test unitaire ici:

http://www.eetimes.com/design/embedded/4007177/Doing-C-code-unit-testing-on-a-shoestring-Part-1-The-basics-and-the-tools

Je serais également d'accord avec tout ce qu'Austin a mentionné.

Essayez les peluches, mais je ne pense pas que ce soit pour les tests unitaires, c'est pour l'analyse de code.