CTA++ : test unitaire pour les languages C et C++

CTA++ - C++ Test Aider (Support de tests C++)

Les informations de cette page correspondent à la version 3.0.2 de CTA++.

1. INTRODUCTION

CTA++ est un outil pour les tests des classes, bibliothèques et sous-systèmes C++. CTA++ est simple à utiliser et propose des fonctionnalités très efficaces, aidant les testeurs à construire les environnements de test et lancer les tests sur le code C++. Le processus de tests est alors efficace, visible et organisé - comme cela est requis dans un environnement de test professionnel.

Les objets orientés, propres au langage C++, bien que très efficaces, impliquent aussi des défis techniques. CTA++ relève ces défis. Ainsi, l'implémentation technique de CTA++ utilise les caractéristiques des objets orientés de C++ d'une nouvelle manière, résultant de capacités très efficaces et très simples à utiliser. Le test du code développé pour la classe de base peut être réutilisé dans des tests de classes dérivées.

CTA++ est un outil idéal pour construire et exécuter avec souplesse une suite de tests efficaces sur le code C++. Le code C peut être testé de la même manière.

Voici quelques liens rapides sur les capacités de CTA++

Utilisation en mode ligne de commande (inclus l'exemple du code soumis au test)
Intégration de CTA++ à Visual Studio (CTA++/VSI)
Échantillon de fichiers d'exécution au banc de tests, convertis au format HTML

Sur toutes les plateformes supportées, CTA++ peut être utilisé en ligne de commande, comme les outils de base. Sur la plate-forme Windows, CTA++ peut en plus être utilisé depuis l'interface utilisateur graphique Visual Studio, pour plus d'informations voir intégration de CTA++ à Visual Studio.

CTA++ est utilisé pour la construction des environnements de test, afin que le code (classes C++, bibliothèques, sous-systèmes, APIs) soit ensuite testé avec le banc de tests. L'architecture CTA++ peut être illustrée de la manière suivante :

Figure: architecture de CTA++

Les tests sont exécutés avec le programme du banc de tests. Il consiste en un test de lecture du code écrit par l'utilisateur (+ les stubs si nécessaires), du code soumis au test, et de la bibliothèque d'exécution de CTA++. Quand le conducteur de tests est construit et que les stubs des services orientés de la bibliothèque d'exécution de soutien de CTA++ sont utilisés. Sur la plate-forme Windows, une partie du conducteur de tests et du fichier stub peut être générée par CTA++/VSI, seul l'essentiel du "test logique" a besoin d'être écrit par l'utilisateur.

D'un coté, l'efficacité de C++ peut être utilisée comme un langage script. De cette façon, bien que le code soumis au test ait été entièrement conçu en C++, comme les modèles, il peut être entièrement testé à l'aide de CTA++. D'un autre coté, grace aux services de la bibliothèque d'exécution de soutien de CTA++, le testeur est épargné d'avoir à implémenter plus que dans le code commun du harnais de tests, comme l'implémentation de la notion d'un cas de test, faisant que le test se lance de manière visible, le mécanisme d'assertion actuel prévoit de reporter la valeur dans les erreurs d'assertion, de reporter et attraper les exceptions non gérées, de comptabiliser les PASS/FAIL, d'approvisionner les données du banc de tests, le contrôle du comportement du stub, le support de tests multicodes, etc. En éditant le conducteur de tests, le testeur peut se concentrer sur l'essentiel, sur le test du code avec des constructions de tests orientés d'un haut niveau et faciles à utiliser. L'infrastructure du test d'exécution vient de CTA++.

Il y a des utilitaires à part pour la génération des stubs de CTA++ depuis les fichiers header (ctastub) et pour les fichiers traces de l'exécution du banc de tests converti textuellement au format HTML convenu (cta2html).

Caractéristiques de CTA++

Étudions à présent quelques caractéristiques de la clé CTA++ dans plus de détails.

2.1. C++ le langage de script

Le potentiel complet de C++ peut être utilisé dans l'écriture des tests du programme principal (test script). Les services de la bibliothèque d'exploitation CTA++ (introduit par le fichier cta.h) sont utilisés dans l'écriture de ce test script. Les services de CTA++ sont une collection de macros, classes, fonctions et modèles pour arranger les tests, aidant tous énormément à l'écriture des tests du programme principal.

2.2. Le modèle CTA++ pour l'arrangement des tests

Les tests de CTA++ sont basés sur des fonctions de tests de cas, conduites par un objet conducteur de test.

Le conducteur de tests supervise les fonctions de tests de cas. Il est créé dans le test du programme principal et les fonctions de tests de cas sont enregistrées dans celui-ci. Le conducteur de tests exécute les cas de tests et garde trace des événements qui ont pris place dans les tests.

2.3. Assertions

Les assertions consistent à vérifier que l'exécution du test a bien eu l'effet que le testeur attendait. CTA++ contient un support efficace pour les assertions, par exemple :

Une expression booléenne a la valeur TRUE
Deux variables comparables (expressions), désignant la valeur actuelle et la valeur attendue, sont en relation spécifique les unes avec les autres (==, !=, >, >=, etc.)
Une variable a actuellement une valeur proche de la valeur attendue
Deux chaînes de caractères ou zone de texte sont égales
L'exécution d'une partie du code ou d'une simple expression provoque une exception spécifiée, ou exécute une exception sans la lancer
Le stub spécifié est appellé exactement dans l'ordre donné

Une assertion échouée est reportée dans le fichier trace. Alors, automatiquement, les valeurs actuelles et attendues sont dissociées. Voici un exemple de comment deux assertions échouées sont indiquées dans le fichier trace :

255: CTA_ASSERT_EQ(pool2.nbr_of_items(), 20)

*** assertion failure, line 255 in file myscript.cc

actual : 0 expected: 20

256: CTA_ASSERT_EXCEPTION(pool2.add(itm2), Pool::overfill_exception)

*** assertion failure, line 256 in file myscript.cc

actual : no exception

expected: exception Pool::overfill_exception

266 CTA_ASSERT_STUBORDER(foo_stub << foo_stub << bar_stub)

... // some test script execution, and later

*** assertion failure, line 34 in file myscript.cc

actual : stub call to bar_stub

expected: stub call to foo_stub

CTA++ garde un enregistrement des assertions exécutées. Une exception échouée ou une exception non gérée font passer le test de cas à l'état FAIL.

2.4. Trace des démarrages de tests, Visibilité du test

Le but des tests est de faire des expériences avec le code soumis au test, dans l'intention de trouver des erreurs. Dans CTA++, les assertions sont les mécanismes primaires pour révéler les erreurs automatiquement.

Il est alors souhaitable de rendre le test visible et automatiquement documenté. Les données suivantes sont alors intéressantes : date et heure indiquant quand les tests ont été exécutés, quel script de test a été utilisé, quels tests de cas ont été exécutés, quels assertions et appels de test ont été faits dans les tests de cas, l'état du test était t'il à PASS ou FAIL, etc. CTA++ donne ces informations dans le fichier trace.

Dans la plupart des cas, l'application utilise des noms symboliques (soit par #define, soit enum) pour les valeurs intégrales variées. CTA++ peut afficher les valeurs intégrales (par exemple dans les échecs d'assertion) en utilisant les noms symboliques, réalisant ainsi un rapport plus utile (ex. : les constantes intégrales 'magic' seraient affichées).

Une trace complète n'est pas toujours désirée. Parfois une vue complète des résultats du test est plus appropriée. CTA++ permet cela par un mode verbosité controlable par le testeur, sur comment le fichier trace doit être écrit :

Verbose mode. Toutes les informations que le script requiert doivent être écrites dans le fichier trace. Alors le cas du test commence et termine en même temps que le résultat PASS/FAIL du cas du test est reporté.
Brief mode. Seul le cas du test commence et termine en même temps que le résultat PASS/FAIL du cas du test est reporté au fichier trace. Les échecs d'assertion et les exceptions peuvent être reportées.
Summary mode. Une seule ligne par cas de test est écrite dans le fichier trace. Elle contient l'identification du test de cas et l'état PASS/FAIL résultant.
Silent mode. Rien n'est ajouté dans le fichier trace. Cependant, un code de retour du programme est remis au niveau du système opérant, indiquant si le test complet est à l'état PASS ou FAIL.

Avec l'utilitaire cta2html, le fichier trace peut être converti dans le format HTML. Avec ce format et en quelques clics, vous pourrez voir la session de test en sommaire, zoom+ ou zoom- sur quelques cas de test spécifiques, afin de voir le détail des niveaux plus avancés, voir le fichier script C++ actuel du cas de test. La représentation HTML utilise des couleurs pour surligner les échecs de test et pour identifier la sortie de la trace des différents sujets.

2.5. Paramétrage de la ligne de commande de lancement de test

Lorsque le programme du banc de tests de CTA++ est exécuté par le niveau de commande du système opérateur, il reconnait quelques paramètres de la ligne de commande, par lesquels le banc de tests peut être davantage paramêtré. Les trois importantes capacités de ligne de commande de CTA++ suivantes sont discutées ici :

Démarrer les cas de test de façon sélective :

Quand un cas de test est enregistré pour être lancé, un ID lui est assigné. Par défaut, tous les cas de tests enregistrés sont lancés. À partir de l'ID du cas de test, vous pouvez demander que seuls les cas de tests spécifiés soient lancés à ce moment-là. Il est aussi possible qu'un seul cas de test soit lancé plusieurs fois.

Prise de contrôle manuel des paramètres de cas de tests:

Une fonction de cas de test a un paramètre. La valeur par défaut de ce paramètre est déterminée lorsque le cas de test est enregistré au conducteur de test. Cependant, tout au long de l'exécution des cas de tests sélectionnés depuis la ligne de commande, vous pouvez changer manuellement la valeur du paramètre pour les cas de tests, si nécessaire. Cela peut être utile quand on expérimente intéractivement comment le code soumis aux tests réagit avec différentes valeurs de données.

Exécution de la session test dans différents modes de verbosité :

Le mode de verbosité du fichier trace peut être spécifié lorsque le banc de tests est appellé.

À présent, en mettant toutes les caractéristiques en commun, le scénario suivant devient possible : d'abord exécuter tous les cas de tests enregistrés. Prendre le mode trace sommaire. Voir quels cas de tests ont échoué. Relancer alors le banc de tests, mais sélectionner cette fois les cas de tests échoués uniquement, et prendre la trace dans le mode Verbose. Étudier le fichier trace détaillé pour faire apparaître les problêmes. Pour finir, davantage de tests peuvent être réalisés avec les cas de test problématiques en leur donnant, par la ligne de commande, la valeur du paramètre modifié. Bien sur, le banc de tests peut également être exécuté à l'aide d'un débuggeur.

2.6. Données de test, fichier de données de tests

Le système CTA++ fournit plusieurs moyens utiles pour l'écriture du programme principal de test (test script). L'un de ces moyens est CTA_Testdata. C'est une classe, qui encapsule la notion de données de tests d'une manière très flexible et facile à utiliser. Les données de tests de CTA++ pourraient être (de manière plus simplifiée) visualisées comme une structure qui peut avoir n'importe quel nombre de membres de données de n'importe quel type. Dans le script de test, les objets de données de tests peuvent être convenablement extraits de l'objet CTA_TestData avec >> operator.

Une des variantes du paramètre de fonction du test de cas est de type CTA_TestData. Lorsqu'un cas de test est explicitement appellé par ligne de commande; l'ensemble de CTA_TestData peut alors être donné.

Une fonction de test de cas (ayant un paramètre CTA_TestData) peut alors être enregistrée afin de lire plus tard son paramètre depuis un fichier de données test textuel. Voici un exemple :

...
TESTDATA "55" {
("Hello", 5, "Hello"),
("How are you?", 12, "I'm fine"),
("How are you?", 3, "Don't understand")
}
...

Il s'agit d'un extrait du fichier de données test. La section ci-dessus contient trois jeux de test de données (l'ensemble de CTA_TestData) pour le cas de test d'ID "55". Quand le cas de test enregistré "55" arrive à exécution, la fonction de cas de test associée est appellée trois fois. Pour chaque appel, l'ensemble de CTA_TestData a été évaluée depuis le fichier de données de test pour le paramètre de la fonction. En fait, le cas de test "55" est un ensemble de 3 cas de test distincts. Le fichier trace montre avec quelles données de test le cas de test a été exécuté sur chaque appel.

La possibilité de controller manuellement les paramètres du cas de test depuis la ligne de commande, et particulièrement le concept de données de test de CTA++, met en évidence l'importante capacité grace à laquelle les données de test peuvent être obtenues à partir d'un programme principal de test logique codé. Le fichier de données de test peut être facilement modifié et étendu sans avoir besoin de recompiler le programme de test principal et relier le banc de tests. Les données de tests peuvent être dans un fichier texte séparé, simple et compact. Il n'y a pas besoin d'être diffus dans le code du banc de tests (le "test execution engine"). Tout ce méchanisme, et bien plus, vous est fourni par le système CTA++.

2.7. Stubs

Les stubs sont des fonctions simulées, dont le comportement est controllé par le testeur et sont appellées par le code actuellement soumis au test. Les besoins typiques pour utiliser les stubs sont les suivants :

Simulation des fonctions dépendant du hardware visé, qui peuvent être lancées dans l'environnement de test hôte.
Simulation des fonctions, qui ne seraient pas encore implémentées.
Arrangement des codes de retour d'erreur "hard-to-produce" pour les fonctions appellées pour assurer l'essai complet du code soumis au test.
Quand les règles du processus de test requièrent un "test en isolation".

CTA++ a un puissant support pour les stubs. Définir un stub et lui faire adopter une attitude intelligente est très facile. Voici un exemple simple pour montrer l'idée :

Dans un script de test, vous pouvez définir dans une portée globale

CTA_STUB (void*, my_alloc(size_t sz), my_alloc_stub)

CTA_BODY(1) {

CTA_PUT(sz)

CTA_ASSERT_IN(sz, 8, 256)

return malloc(sz);

}

CTA_BODY(2) {return malloc(sz);}

CTA_ENDSTUB

Dans plusieurs fonctions des tests de cas, il pourrait, alors, y avoir

my_alloc_stub.actionList() << repeat(5) << body(1) << repeat() << body(2);

Ce qui signifie que lors des 5 prochains appels de "my_alloc", il réagira selon CTA_BODY(1), et ensuite il réagira de manière indéfinie selon CTA_BODY(2).

Plus tard, vous pourriez vouloir tester la manière de laquelle le code soumis au test gère la condition et définit le stub

my_alloc_stub << 0;

Ce qui signifie que le stub renvoie 0 (pointeur nul) chaque fois qu'il est appellé à présent.

CTA++ a un utilitaire (ctastub), qui lit un fichier header et génère des définitions de stub CTA++ sans comportement pour le stand alone et les fonctions membres que le fichier header contient. Plus tard, il vous sera facile d'éditer une intelligence pour le stub comme le nécessite la situation de test. L'infrastructure pour utiliser les stubs est fournie par CTA++.

2.8. Test de code multithreads

CTA++ est implémenté pour gérer les tests de code multithreads. Premièrement, le code soumis au test pourrait avoir été divisé en différents threads et chacun d'eux peut faire appel aux mêmes fonctions globales de stubs.

Deuxièmement, cela pourrait être un cas plus intéressant, le programme principal de test pourrait lui-même se diviser en threads. Chacun de ces threads pouvant s'assigner son propre conducteur de test, qui s'exécute en parallèle. Ainsi il est possible de faire un arrangement de test où le code soumis au test est appellé en parallèle depuis plusieurs threads. Le testeur peut installer, là où cela serait nécessaire, des mécanismes synchronisés entre les threads, et obtenir un appel controlé qui commanderait depuis les threads.

2.9. Accès à Object Private Members

CTA++ a un mécanisme permettant aux Object Private Members d'accéder au timing de test (dans le programme principal de test et dans les fonctions de cas de test).

2.10. Usage avec les outils de couverture de code

Du point de vue du système opérant, un banc de tests CTA++ est un programme normal. Un outil de couverture peut être appliqué sur le code soumis au test afin de déterminer si tout le code est exercé. Par exemple CTC++ de Testwell, analyseur de couverture de tests pour C et C++, peut être utilisé.

2.11. Usage avec des outils de détection des erreurs d'exécution

Les outils de détection des erreurs d'exécution révèlent des fuites de mémoire, un mauvais usage des pointeurs, écrasement par réécriture de la mémoire tampon, mauvais appels du système opérant, etc.

Premièrement, n'importe quel outil de détection des erreurs d'exécution peut etre appliqué, car le banc de tests de CTA++ est un programme normal. L'outil trouvé est lancé par banc de tests complet.

Deuxièmement, si l'outil de détection d'erreur a une API, une étape supplémentaire peut être prise. CTA++ supporte un moyen original indiquant comment l'outil de détection d'erreurs peut être intégré au modèle CTA++ du conducteur de test et des cas de tests. Comme résultat, le testeur peut lire depuis le fichier trace CTA++ dans quel cas de test la mémoire a fui, ou plusieurs autres anomalies produites détectées par l'outil.

2.12. Réutilisation du code de test

Supposons une situation où une classe a été développée (classe A) et a été testée par CTA++. Ainsi, pour la classe A, il y a une suite de tests CTA++. Plus concrètement, il existe une collection de fonctions de cas de tests, chacune testant plusieurs propriétés fonctionnelles des objets types classe A.

Supposez alors que, plus tard, la classe B soit dérivée de la classe A et que le développeur soit confronté à la tache de tester cette nouvelle classe B. Supposant que la classe B corresponde toujours aux propriétés de la classe A, ici il serait maniable pour pouvoir réutiliser le code de test (cas de test) qu'il y a déjà pour le test de la classe A.

CTA++ facilite des moyens francs d'arranger les tests de façon que les fonctions de cas de test pour les types d'objets de la classe A puissent également être employées pour tester les types d'objets de la classe B (ou toute classe héritée). Pour tester la classe B seulement, des fonctions de cas de test doivent être développées, permettant de tester la nouvelle fonctionnalité de la classe B. La fonction de cas de test existante pour la classe peut être réutilisée dans le test de la classe B.

3. UTILISATION DE CTA++/EXEMPLE

3.1. Le code soumis au test

Nous avons l'interface du code soumis au test dans le fichier list.h. Il contient plusieurs déclarations de classe. Dans cet exemple nous testerons les opérations de la liste de classe. Le dossier d'exécution est dans list_bug_cpp. Le fichier list_bug_cpp appelle plusieurs fonctions, dont l'interface est déclarée dans le fichier memory.h. Dans cet exemple nous employons des stubs pour les fonctions déclarées dans le fichier memory.h.

3.2. Ce qui doit être fait pour le banc de tests

Tous les bancs de tests CTA++ ont besoin d'un programme principal de tests. Il contient la fonction main() de banc de tests, les fonctions de tests de cas, etc., voir CTA_vsList_drv_cpp. Pour les stubs nous avons édité le fichier CTA_memory_h_stb_inc. Le fichier CTA_vsList_drv_cpp contient le fichier de définition des stubs. Dans cet exemple, nous utilisons également un fichier de données pour alimenter le banc de tests de données de test, voir CTA_vsList_drv_dat. Tous ces trois fichiers sont ici initiallement générés par CTA++/VSI (d'où leur nom et certaines "oding conventions"), mais ils pourraient avoir été édités directement par l'utilisateur.

3.3. Utilisation du mode ligne de commande

Le banc de tests CTA++ ci-dessus pourrait être compilé comme n'importe quel programme C++, comme l'exemple suivant :

cl -Febed.exe list_bug.cpp CTA_vsList_drv.cpp cta.lib

Le programme résultant bed.exe reconnait un certain ensemble de paramètres de ligne de commande (la verbosité du banc de tests démarré, où écrire la trace, démarrer seulement les cas de tests sélectionnés, donner d'autres paramètres au lancement du banc de tests). Par exemple, il pourrait être lancé comme suit (tous les cas de tests dans lui-même) :

bed -o trace.txt

Ensuite, le fichier trace pourrait être converti au format HTML de la façon suivante :

cta2html -i trace.txt

Et vous pourriez le visualiser avec votre navigateur avec cette commande :

start CTAHTML\index.html

Voir le rapport HTML complet ici (le banc de tests a été construit, compilé et lancé via CTA++/VSI, mais le même contenu pourrait avoir été ainsi achevé efficacement en mode ligne de commande).

3.4. Intégration de CTA++ à Visual Studio

Sur Windows, l'usage de CTA++ peut être réalisé intégralement dans l'IDE Visual Studio. Voir une description plus détaillée de CTA++/VSI.

4. RÉSUMÉ DES AVANTAGES

Les avantages de CTA++ peuvent être résumés ainsi :

Exécution de tests automatiques
Tests répétables, tests de régression
Visibilité et documentation de l'exécution des tests
Représentation HTML des résultats des tests, montrant un résumé et des vues détaillées
Rapports dans le domaine d'application ('application domain', affichable dans des noms symboliques #define/enum)
Réutilisation du travail sauvegardé des tests de cas dans les classes dérivées testées
Premier test d'unité
Tests en isolation (utilisation de stubs)
Plus de tests possibles dans l'environnement hôte (utilisation de stubs)
Génération de stubs depuis les fichiers header
Sur une plate-forme Windows Intégration de CTA++ à Visual Studio

Les bancs de tests CTA++ peuvent être utilisés en même temps que CTC++ de Testwell, analyseur de couverture de tests pour C et C++ (voir description de CTC++). Lorsqu'ils sont utilisés ensemble, CTA++ donne la boîte noire (comportementale) de l'approche de tests et CTC++ donne la boîte blanche (structurelle) de l'approche de tests. Les bancs de tests CTA++ sont "les moteurs d'exécution de tests" avec une forte automatisation. CTC++ est utilisé pour mesurer que tout le code a été exercé durant les tests.

5. ENVIRONNEMENTS OPÉRANTS

CTA++ est disponible sur les machines/systèmes d'exploitation/compilateurs C++ suivants : disponibilités de CTA++.

CTA++ est facilement portatif à n'importe quel environnement, mais le compilateur de C++ utilisé doit être assez récent pour supporter certaines caractéristiques de C++ plus récentes (support robuste sur les templates, exceptions et RTTI pour en mentionner quelques uns).

Demander une évaluation gratuite de CTA++

Brochure CTA++ (2 pages) (format PDF)

last updated: 21.02.2006

© 1998-2005 Testwell Oy © 2006 Verifysoft Technology for the french translation
CTA++, CTC++, CMT++ and CMTJava are products of Testwell Oy, Tampere (Finland)
all other trademarks of this site are the property of their respective owners.

CTA++ – test unitaire pour C et C++