J'aimerais pouvoir tester mon code Arduino unitaire. Idéalement, je serais capable d'exécuter des tests sans avoir à télécharger le code sur l'Arduino. Quels outils ou bibliothèques peuvent m'aider à cet égard?

Il existe un émulateur Arduino en développement qui pourrait être utile, mais il ne semble pas encore prêt à être utilisé.

AVR Studio d'Atmel contient un simulateur de puce qui pourrait être utile, mais je ne vois pas comment je l'utiliserais en conjonction avec l'IDE Arduino.

N'exécutez pas de tests unitaires sur le périphérique ou l'émulateur Arduino

Les arguments contre les tests basés sur un périphérique / émulateur / simulateur de microcontrôleur

Il y a beaucoup de discussions sur ce que signifie le test unitaire et je n'essaie pas vraiment d'argumenter à ce sujet ici. Cet article ne vous dit pas d'éviter tous les tests pratiques sur votre matériel cible ultime. J'essaie de faire un point sur l'optimisation de votre cycle de rétroaction de développement en éliminant votre matériel cible de vos tests les plus banals et les plus fréquents. Les unités testées sont supposées être beaucoup plus petites que l'ensemble du projet.

Le but des tests unitaires est de tester la qualité de votre propre code. Les tests unitaires ne doivent généralement jamais tester la fonctionnalité de facteurs indépendants de votre volonté.

Pensez-y de cette façon: même si vous deviez tester les fonctionnalités de la bibliothèque Arduino, du matériel du microcontrôleur ou d'un émulateur, il est absolument impossible que de tels résultats de test vous disent quoi que ce soit sur la qualité de votre propre travail. Par conséquent, il est beaucoup plus précieux et efficace d'écrire des tests unitaires qui ne s'exécutent pas sur le périphérique cible (ou l'émulateur).

Les tests fréquents sur votre matériel cible ont un cycle extrêmement lent:

1. Ajustez votre code
2. Compiler et télécharger sur un appareil Arduino
3. Observez le comportement et devinez si votre code fait ce que vous attendez
4. Répéter

L'étape 3 est particulièrement désagréable si vous vous attendez à recevoir des messages de diagnostic via le port série mais que votre projet lui-même doit utiliser le seul port série matériel de votre Arduino. Si vous pensiez que la bibliothèque SoftwareSerial pourrait vous aider, sachez que cela risquerait de perturber toute fonctionnalité nécessitant une synchronisation précise, comme la génération d'autres signaux en même temps. Ce problème m'est arrivé.

Encore une fois, si vous deviez tester votre esquisse à l'aide d'un émulateur et que vos routines critiques en temps fonctionnaient parfaitement jusqu'à ce que vous le téléchargiez sur l'Arduino réel, la seule leçon que vous allez apprendre est que l'émulateur est défectueux - et le sachant toujours. ne révèle rien sur la qualité de votre propre travail.

S'il est ridicule de tester sur l'appareil ou l'émulateur, que dois- je faire?

Vous utilisez probablement un ordinateur pour travailler sur votre projet Arduino. Cet ordinateur est des ordres de grandeur plus rapide que le microcontrôleur. Écrivez les tests à construire et à exécuter sur votre ordinateur .

N'oubliez pas que le comportement de la bibliothèque Arduino et du microcontrôleur doit être considéré comme correct ou du moins systématiquement incorrect .

Lorsque vos tests produisent une sortie contraire à vos attentes, vous avez probablement une faille dans votre code qui a été testé. Si la sortie de votre test correspond à vos attentes, mais que le programme ne se comporte pas correctement lorsque vous le téléchargez sur l'Arduino, vous savez que vos tests étaient basés sur des hypothèses incorrectes et que vous avez probablement un test défectueux. Dans les deux cas, vous aurez reçu de véritables informations sur ce que devraient être vos prochains changements de code. La qualité de vos commentaires est améliorée de " quelque chose est cassé" à "ce code spécifique est cassé" .

Comment créer et exécuter des tests sur votre PC

La première chose à faire est d' identifier vos objectifs de test . Pensez aux parties de votre propre code que vous souhaitez tester, puis assurez-vous de construire votre programme de manière à pouvoir isoler les parties discrètes pour les tests.

Si les pièces que vous souhaitez tester appellent des fonctions Arduino, vous devrez fournir des remplacements de maquette dans votre programme de test. C'est beaucoup moins de travail qu'il n'y paraît. Vos maquettes n'ont rien d'autre à faire que de fournir des entrées et des sorties prévisibles pour vos tests.

Tout code que vous avez l'intention de tester doit exister dans des fichiers source autres que l'esquisse .pde. Ne vous inquiétez pas, votre esquisse sera toujours compilée même avec du code source en dehors de l'esquisse. Lorsque vous y arrivez vraiment, un peu plus que le point d'entrée normal de votre programme devrait être défini dans le fichier d'esquisse.

Il ne reste plus qu'à écrire les tests réels, puis à les compiler à l'aide de votre compilateur C ++ préféré! Ceci est probablement mieux illustré par un exemple du monde réel.

Un exemple de travail réel

L'un de mes projets favoris trouvés ici a quelques tests simples qui s'exécutent sur le PC. Pour cette soumission de réponse, je vais juste passer en revue la façon dont j'ai simulé certaines des fonctions de la bibliothèque Arduino et les tests que j'ai écrits pour tester ces maquettes. Ce n'est pas contraire à ce que j'ai dit précédemment sur le fait de ne pas tester le code des autres parce que c'est moi qui ai écrit les maquettes. Je voulais être très certain que mes maquettes étaient correctes.

Source de mock_arduino.cpp, qui contient du code qui duplique certaines fonctionnalités de support fournies par la bibliothèque Arduino:

#include <sys/timeb.h>
#include "mock_arduino.h"

timeb t_start;
unsigned long millis() {
  timeb t_now;
  ftime(&t_now);
  return (t_now.time  - t_start.time) * 1000 + (t_now.millitm - t_start.millitm);
}

void delay( unsigned long ms ) {
  unsigned long start = millis();
  while(millis() - start < ms){}
}

void initialize_mock_arduino() {
  ftime(&t_start);
}

J'utilise la maquette suivante pour produire une sortie lisible lorsque mon code écrit des données binaires sur le périphérique série matériel.

fake_serial.h

#include <iostream>

class FakeSerial {
public:
  void begin(unsigned long);
  void end();
  size_t write(const unsigned char*, size_t);
};

extern FakeSerial Serial;

fake_serial.cpp

#include <cstring>
#include <iostream>
#include <iomanip>

#include "fake_serial.h"

void FakeSerial::begin(unsigned long speed) {
  return;
}

void FakeSerial::end() {
  return;
}

size_t FakeSerial::write( const unsigned char buf[], size_t size ) {
  using namespace std;
  ios_base::fmtflags oldFlags = cout.flags();
  streamsize oldPrec = cout.precision();
  char oldFill = cout.fill();

  cout << "Serial::write: ";
  cout << internal << setfill('0');

  for( unsigned int i = 0; i < size; i++ ){
    cout << setw(2) << hex << (unsigned int)buf[i] << " ";
  }
  cout << endl;

  cout.flags(oldFlags);
  cout.precision(oldPrec);
  cout.fill(oldFill);

  return size;
}

FakeSerial Serial;

et enfin, le programme de test proprement dit:

#include "mock_arduino.h"

using namespace std;

void millis_test() {
  unsigned long start = millis();
  cout << "millis() test start: " << start << endl;
  while( millis() - start < 10000 ) {
    cout << millis() << endl;
    sleep(1);
  }
  unsigned long end = millis();
  cout << "End of test - duration: " << end - start << "ms" << endl;
}

void delay_test() {
  unsigned long start = millis();
  cout << "delay() test start: " << start << endl;
  while( millis() - start < 10000 ) {
    cout << millis() << endl;
    delay(250);
  }
  unsigned long end = millis();
  cout << "End of test - duration: " << end - start << "ms" << endl;
}

void run_tests() {
  millis_test();
  delay_test();
}

int main(int argc, char **argv){
  initialize_mock_arduino();
  run_tests();
}

Cet article est assez long, veuillez donc vous référer à mon projet sur GitHub pour voir d'autres cas de test en action. Je garde mes travaux en cours dans des branches autres que master, donc vérifiez également ces branches pour des tests supplémentaires.

J'ai choisi d'écrire mes propres routines de test légères, mais des frameworks de tests unitaires plus robustes comme CppUnit sont également disponibles.

En l'absence de tout framework de test unitaire préexistant pour Arduino, j'ai créé ArduinoUnit . Voici un simple croquis Arduino démontrant son utilisation:

#include <ArduinoUnit.h>

// Create test suite
TestSuite suite;

void setup() {
    Serial.begin(9600);    
}

// Create a test called 'addition' in the test suite
test(addition) {
    assertEquals(3, 1 + 2);
}

void loop() {
    // Run test suite, printing results to the serial port
    suite.run();
}

J'ai un succès considérable dans les tests unitaires de mon code PIC en supprimant l'accès au matériel et en le moquant dans mes tests.

Par exemple, je résume PORTA avec

#define SetPortA(v) {PORTA = v;}

Ensuite, SetPortA peut facilement être simulé, sans ajouter de code de surcharge dans la version PIC.

Une fois que l'abstraction matérielle a été testée un certain temps, je constate rapidement que le code passe généralement du banc de test au PIC et fonctionne du premier coup.

Mettre à jour:

J'utilise une couture #include pour le code de l'unité, #incluant le code de l'unité dans un fichier C ++ pour le banc de test et un fichier C pour le code cible.

À titre d'exemple, je souhaite multiplexer quatre écrans à 7 segments, un port pilotant les segments et un second sélectionnant l'affichage. Le code d'affichage s'interface avec les affichages via SetSegmentData(char)et SetDisplay(char). Je peux me moquer de ceux-ci dans mon banc de test C ++ et vérifier que j'obtiens les données attendues. Pour la cible que j'utilise #defineafin d'obtenir une affectation directe sans la surcharge d'un appel de fonction

#define SetSegmentData(x) {PORTA = x;}

Il semble que l' émulino ferait parfaitement l'affaire.

Emulino est un émulateur pour la plate-forme Arduino de Greg Hewgill. ( Source )

Dépôt GitHub

simavr est un simulateur AVR utilisant avr-gcc.

Il prend déjà en charge quelques microcontrôleurs ATTiny et ATMega, et - selon l'auteur - il est facile d'en ajouter d'autres.

Dans les exemples se trouve simduino, un émulateur Arduino. Il prend en charge l'exécution du chargeur de démarrage Arduino et peut être programmé avec avrdude via Socat (un Netcat modifié ).

Vous pouvez effectuer des tests unitaires en Python avec mon projet PySimAVR . Arscons est utilisé pour la construction et simavr pour la simulation.

Exemple:

from pysimavr.sim import ArduinoSim    
def test_atmega88():
    mcu = 'atmega88'
    snippet = 'Serial.print("hello");'

    output = ArduinoSim(snippet=snippet, mcu=mcu, timespan=0.01).get_serial()
    assert output == 'hello'

Démarrer le test:

$ nosetests pysimavr/examples/test_example.py
pysimavr.examples.test_example.test_atmega88 ... ok

Je ne connais aucune plate-forme capable de tester le code Arduino.

Cependant, il existe la plate-forme Fritzing , que vous pouvez utiliser pour modéliser le matériel et plus tard pour exporter des diagrammes de circuits imprimés et d'autres choses.

Ça vaut le coup de vérifier.

Nous utilisons des cartes Arduino pour l'acquisition de données dans le cadre d'une grande expérience scientifique. Par la suite, nous devons prendre en charge plusieurs cartes Arduino avec différentes implémentations. J'ai écrit des utilitaires Python pour charger dynamiquement des images hexadécimales Arduino pendant les tests unitaires. Le code trouvé sur le lien ci-dessous prend en charge Windows et Mac OS X via un fichier de configuration. Pour savoir où vos images hexadécimales sont placées par l'IDE Arduino, appuyez sur la touche Maj avant d'appuyer sur le bouton de construction (lecture). Appuyez sur la touche Maj tout en appuyant sur le téléchargement pour savoir où se trouve votre avrdude (utilitaire de téléchargement en ligne de commande) sur votre système / version d'Arduino. Vous pouvez également consulter les fichiers de configuration inclus et utiliser votre emplacement d'installation (actuellement sur Arduino 0020).

http://github.com/toddstavish/Python-Arduino-Unit-Testing

Ce programme permet l'exécution automatisée de plusieurs tests unitaires Arduino. Le processus de test démarre sur le PC mais les tests s'exécutent sur le matériel Arduino réel. Un ensemble de tests unitaires est généralement utilisé pour tester une bibliothèque Arduino. (ce

Forum Arduino: http://arduino.cc/forum/index.php?topic=140027.0

Page du projet GitHub: http://jeroendoggen.github.com/Arduino-TestSuite

Page dans l'index des packages Python: http://pypi.python.org/pypi/arduino_testsuite

Les tests unitaires sont écrits avec la "Arduino Unit Testing Library": http://code.google.com/p/arduinounit

Les étapes suivantes sont effectuées pour chaque ensemble de tests unitaires:

• Lisez le fichier de configuration pour savoir quels tests exécuter
• Le script compile et télécharge une esquisse Arduino qui contient le code de test unitaire.
• Les tests unitaires sont exécutés sur la carte Arduino.
• Les résultats du test sont imprimés sur le port série et analysés par le script Python.
• Le script démarre le test suivant, en répétant les étapes ci-dessus pour tous les tests demandés dans le fichier de configuration.
• Le script imprime un résumé montrant un aperçu de tous les tests échoués / réussis dans la suite de tests complète.

Gardez le code spécifique au matériel séparé ou abstrait du reste afin de pouvoir tester et déboguer ce plus gros «repos» sur n'importe quelle plate-forme pour laquelle vous avez de bons outils et avec laquelle vous êtes le plus familier.

En gros, essayez de créer autant de code final à partir d'autant de blocs de construction connus que possible. Le travail restant spécifique au matériel sera alors beaucoup plus facile et plus rapide. Vous pouvez le terminer en utilisant vous-même des émulateurs et / ou des dispositifs d'émulation existants. Et puis, bien sûr, vous devrez tester la réalité d'une manière ou d'une autre. Selon les circonstances, cela peut être très bien automatisé ou non (c'est-à-dire qui ou quoi appuiera sur les boutons et fournira d'autres entrées? Qui ou quoi observera et interprétera divers indicateurs et résultats?).

James W. Grenning écrit de grands livres et celui - ci est sur les tests unitaires du code embarqué C Test Driven Development pour Embedded C .

J'utilise Searduino lors de l'écriture de code Arduino. Searduino est un simulateur Arduino et un environnement de développement (Makefiles, code C ...) qui facilite le piratage en C / C ++ à l'aide de votre éditeur préféré. Vous pouvez importer des croquis Arduino et les exécuter dans le simulateur.

Capture d'écran de Searduino 0.8: http://searduino.files.wordpress.com/2014/01/jearduino-0-8.png

Searduino 0.9 sortira et une vidéo sera enregistrée dès que les derniers tests seront effectués .... dans un jour ou deux.

Tester sur le simulateur ne doit pas être considéré comme de vrais tests, mais cela m'a certainement beaucoup aidé à trouver des erreurs stupides / logiques (oublier de faire pinMode(xx, OUTPUT), etc.).

BTW: Je suis l'une des personnes qui développent Searduino.

J'ai construit arduino_cidans ce but. Bien qu'il se limite à tester des bibliothèques Arduino (et non des croquis autonomes), il permet d'exécuter des tests unitaires soit localement, soit sur un système CI (comme Travis CI ou Appveyor).

Considérez une bibliothèque très simple dans votre répertoire de bibliothèque Arduino, appelée DoSomething, avec do-something.cpp:

#include <Arduino.h>
#include "do-something.h"

int doSomething(void) {
  return 4;
};

Vous le testeriez unitaire comme suit (avec un fichier de test appelé test/is_four.cppou un autre):

#include <ArduinoUnitTests.h>
#include "../do-something.h"

unittest(library_does_something)
{
  assertEqual(4, doSomething());
}

unittest_main()  // this is a macro for main().  just go with it.

C'est tout. Si cette assertEqualsyntaxe et cette structure de test vous semblent familières, c'est parce que j'ai adopté une partie de la bibliothèque ArduinoUnit de Matthew Murdoch qu'il a mentionnée dans sa réponse .

Voir Reference.md pour plus d'informations sur les tests unitaires des broches d'E / S, de l'horloge, des ports série, etc.

Ces tests unitaires sont compilés et exécutés à l'aide d'un script contenu dans une gemme ruby. Pour obtenir des exemples de configuration, consultez le fichier README.md ou copiez simplement l'un de ces exemples:

• Un exemple pratique, test d'une implémentation de file d'attente
• Un autre ensemble de tests sur un autre projet de file d'attente
• Un exemple complexe, simulant une bibliothèque qui contrôle un appareil interactif via une connexion SoftwareSerial dans le cadre de la bibliothèque Adafruit FONA
• L' exemple de bibliothèque DoSomething montré ci-dessus, utilisé pour tester arduino_ci lui-même

Il existe un projet appelé ncore , qui fournit un noyau natif pour Arduino. Et vous permet d'écrire des tests pour le code Arduino.

À partir de la description du projet

Le noyau natif vous permet de compiler et d'exécuter des croquis Arduino sur le PC, généralement sans modification. Il fournit des versions natives des fonctions Arduino standard et un interpréteur de ligne de commande pour donner des entrées à votre croquis qui proviendraient normalement du matériel lui-même.

Également dans la section "De quoi ai-je besoin pour l'utiliser"

Si vous souhaitez créer les tests, vous aurez besoin de cxxtest de http://cxxtest.tigris.org . NCORE a été testé avec cxxtest 3.10.1.

Si vous souhaitez tester un code en dehors de MCU (sur le bureau), consultez libcheck: https://libcheck.github.io/check/

Je l'ai utilisé pour tester mon propre code embarqué à quelques reprises. C'est un cadre assez robuste.

Vous pouvez utiliser emulare - vous pouvez faire glisser et déposer un microcontrôleur sur un diagramme et exécuter votre code dans Eclipse. La documentation sur le site Web vous explique comment le configurer.

Utilisez Proteus VSM avec une bibliothèque Arduino pour déboguer votre code ou pour le tester.

C'est une bonne pratique avant d'intégrer votre code, mais assurez-vous de respecter les délais, car la simulation ne s'exécute pas en temps réel lorsqu'elle s'exécute sur la carte.

Essayez le simulateur de circuit Autodesk . Il permet de tester le code et les circuits Arduino avec de nombreux autres composants matériels.

Dans Arduino de base est écrit avec C et C ++, même les bibliothèques d'arduino sont écrites en C et C ++. Donc, en termes simples, gérez simplement le code en C et C ++ et essayez de faire les tests unitaires. Ici, par le mot «handle», je veux dire que vous devez changer toute la syntaxe de base comme serial.println en sysout, pinmode en varaibles, boucle vide en boucle while () qui se brise soit dans keystock ou après une certaine itération.

Je sais que ce processus est un peu long et pas si simple.Selon mon expérience personnelle, une fois que vous avez compris, cela s'avère plus fiable.

-Nandha_Frost

Si vous souhaitez exécuter un croquis INO et vérifier la sortie série, j'en ai une implémentation fonctionnelle dans mon projet de somme de contrôle Arduino NMEA .

Le script suivant prend le fichier et utilise Arduino CLI pour le compiler dans un fichier HEX qui est ensuite chargé dans SimAVR qui l'évalue et imprime la sortie série. Étant donné que tous les programmes Arduino fonctionnent pour toujours sans vraiment avoir la possibilité de se tuer ( exit(0)ne fonctionne pas), je laisse le croquis s'exécuter pendant quelques secondes, puis je diffère la sortie capturée avec la sortie attendue.

Téléchargez et extrayez la CLI Arduino (dans ce cas, la version 0.5.0 - la dernière au moment de la rédaction):

curl -L https://github.com/arduino/arduino-cli/releases/download/0.5.0/arduino-cli_0.5.0_Linux_64bit.tar.gz -o arduino-cli.tar.gz
tar -xvzf arduino-cli.tar.gz

Vous pouvez maintenant mettre à jour l'index et installer le noyau approprié:

./arduino-cli core update-index
./arduino-cli core install arduino:avr

En supposant que votre esquisse est nommée nmea-checksum.ino, pour obtenir ELF et HEX, exécutez:

./arduino-cli compile -b arduino:avr:uno nmea-checksum.ino

Ensuite, SimAVR pour exécuter HEX (ou ELF) - Je construis à partir des sources car la dernière version ne fonctionnait pas pour moi:

sudo apt-get update
sudo apt-get install -y build-essential libelf-dev avr-libc gcc-avr freeglut3-dev libncurses5-dev pkg-config
git clone https://github.com/buserror/simavr.git
cd simavr
make

Une compilation réussie vous donnera ce simavr/run_avrque vous pouvez utiliser pour exécuter l'esquisse. Comme je l'ai dit, timeoutsinon cela ne se terminera jamais:

cd simavr
timeout 10 ./run_avr -m atmega168 -f 16000000 ../../nmea-checksum.ino.arduino.avr.uno.elf &> nmea-checksum.ino.clog || true

Le fichier généré aura des caractères de contrôle de code couleur ANSI enveloppant la sortie série, pour se débarrasser de ceux-ci:

cat nmea-checksum.ino.clog | sed -r "s/\x1B\[([0-9]{1,2}(;[0-9]{1,2})?)?[mGK]//g" > nmea-checksum.ino.log
cat nmea-checksum.ino.log

Il ne vous reste plus qu'à comparer ce fichier à un bon fichier connu:

diff nmea-checksum.ino.log ../../nmea-checksum.ino.test

S'il n'y a pas de différences, se diffterminera avec le code 0, sinon le script échouera.