Module 3 : Considérations de génie logiciel Flashcards
étape modèle en cascade
spécifier besoin
analyse
conception
implémenter
intégrer
maintenir
processus de compilation
pré processeur
compilateur
éditeur de liens
Test unitaire ?
Pour s’assurer qu’un composant logiciel se comporte tel que prévu et spécifié.
Teste les cas normaux et les cas anormaux.
Utilise toujours de façon systématique
l’interface publique de la classe.
but test unitaire
Première ligne de défense contre les défauts du logiciel.
Permet de détecter toute anomalie le plus tôt possible
Mise en œuvre test unitaires
Doit être structuré.
Doit être répétable
Doit fournir un rapport d’exécution extrêmement
simple
Toutes les méthodes publiques de la classe doivent être testées.
Les tests pour chaque méthode doivent être indépendants les uns des autres
assertions
déclarations vérifiant si une condition est vraie
résultat d’une assertion
success (test réussi),
nonfatal failure (test échoué)
fatal failure (test échoué et arrête la fonction).
exemple de code de test
TEST(Pile,ConstructeurVide)
{
Pile unePile; ASSERT_EQ(0,unePile.getCapacite()); ASSERT_TRUE(unePile.estVide());
}
TEST(Pile,ConstructeurCapacite)
{
Pile unePile(25); ASSERT_EQ(25,unePile.getCapacite()); ASSERT_TRUE(unePile.estVide());
2 types d’assertions:
EXPECT_* : assertions non-fatales (continue après échec)
ASSERT_* : assertions fatales (arrête le programme)
oPrincipales macros:
ASSERT/EXPECT_TRUE/FALSE(condition)
ASSERT/EXPECT_EQ(v1, v2)/_NE()/_LT()/_LE()/_GT()/_GE()
comparaisons entre deux valeurs v1 et v2 (valeurs comparables)
Si 2 tests ou plus opèrent sur des données similaires
o les regrouper dans
un test fixture
Pour créer un fixture
Dériver la classe de ::testing::Test. Commencer le corps de la classe avec le mot-clé protected ou public pour que son contenu soit accessible par les sous-classes
Déclarer dans la classe tous les objets à utiliser
Si nécessaire, écrire un constructeur par défaut ou une fonction SetUp() pour préparer les objets pour chaque test (Attention! Veiller à bien écrire SetUp() avec un «u» majuscule)
Si nécessaire, écrire un destructeur ou une fonction TearDown() pour libérer la mémoire allouée dans SetUp()
Au besoin, définir les sous-routines partagées par les tests
oPour des tests utilisant un fixture, on écrira – au
lieu de –
oPour des tests utilisant un fixture, on écrira TEST_F() au
lieu de TEST()
On doit faire un test pour quelles méthodes?
Méthode publique, pourquoi pas les méthodes privées car c’est testé à travers les publiques: on garantit aux utilisateurs de la classe qui vont utiliser les méthode publique. Les méthodes publiques c’est l’interface avec l’utilisateur. Donc les tests unitaires, on se met à la place de l’utilisateur.
Quelle mécanique doit-on utiliser pour les tests?
Google test. Test unitaire pour éliminer les effets de bord d’un test à un autre. On teste une chose à la fois. Les tests doivent être indépendants
Quel genre de rapport sera fourni à la fin du test?
Rapport simpliste de pass/fail.
Un contrat protège les deux parties
Protège le client (dans ce cas ci vous-mêmes)
oSpécifie quelles sont ses obligations.
oEn retour, est assuré d’un certain résultat.
Protège le fournisseur (sous-contractant)
oSpécifie le minimum requis (de la part du client):
le fournisseur ne peut être tenu responsable d’avoir manqué à des engagements ne figurant pas dans le contrat.
spécification d’un contrat
Spécification d’une interface
peut être vue comme un contrat entre un client (l’utilisateur du
composant/classe) et un fournisseur (le composant/classe).
Le contrat dit ce qui doit être rencontré par le client
pour pouvoir appeler une opération de l’interface :
précondition.
Le contrat dit aussi ce qui doit être réalisé par le fournisseur
de fait, ce qui est garanti au client
pour rencontrer ce qui est prévu par l’opération
postcondition.
Mécanismes pour exprimer ces conditions
assertions
préconditions
postconditions :
assertions s’appliquant à des méthodes en particulier,
invariants de classe :
assertions s’appliquant à toutes les méthodes d’une classe en tout temps.
préconditions
conditions devant être remplies avant
d’exécuter une méthode.
Si le contrat n’est pas rempli, la méthode n’a pas à s’exécuter. [Erreur de programmation]
postconditions :
conditions devant être remplies après
l’exécution d’une méthode.
Si le contrat n’est pas rempli, la méthode ne doit
pas retourner. [Erreur de programmation]
Une spécification plus complète d’une opération offerte par un composant deviendrait
ole nom de l’opération
ole nombre, le type et l’ordre des paramètres
oles préconditions oles postconditions ole type de retour
invariant
oreprésente l’ensemble des conditions logiques devant être respectées pour assurer un comportement correct d’une classe.
Les invariants doivent donc être respectés (et testés) :
à la fin de tous les constructeurs.
o à la fin de toutes les méthodes non constantes,
i.e. les méthodes qui modifient l’objet
règle absolue des précondition et postconditions
osoit on a la condition dans la précondition,
osoit on l’a dans le corps de la méthode,
jamais dans les deux.
Les bénéfices des contrats
Les spécifications des services sont claires;
Les contrats offrent un moyen explicite pour documenter et transférer ces spécifications directement dans le code;
Spécifications dans le code
On peut les tester = on peut garantir la fiabilité du code.
L’utilisation des contrats est vitale pour la réutilisation
de composants.
Les MACROs pour le contrat
“fonction” définie par un #define.
Remplacement textuel, fait par le préprocesseur.
Dans le fichier ContratException.h,
Définition de ces classes
+ définition des MACROs suivantes:
PRECONDITION(test);
POSTCONDITION(test);
ASSERTION(test);
INVARIANT(test);
INVARIANTS();
Implantation du contrat au niveau d’une méthode
Utilisation des MACROs:
oPRECONDITION(«test_logique»);
pour valider les données en entrée.
oPOSTCONDITION(«test_logique»);
pour valider le bon fonctionnement de la méthode avant le retour de celle-ci.
oASSERTION(«test_logique»);
pour valider un état quelconque au milieu de l’algorithmique
