Module: Intégration et Tests

Expert : votre encadrant GL

coordinateur: Jean-Claude Dufourd, email : dufourd_at_telecom-paris.fr

Vérifier que chaque module implémente l’interface prévue (par compilation)
Vérifier que chaque module a été testé (présence de tests dans le module)
Créer les tests globaux, équivalents des méthodes de tests des modules au niveau du projet entier
- tests de fonctionnalité : ça fait ce qu’il faut
- tests de performance : ça va assez vite
- tests d’utilisabilité : c’est compréhensible par un utilisateur extérieur
- …
Appliquer un par un les cas de tests globaux prévus dans le plan de test:
- Faire des retours aux créateurs des modules sur les problèmes.
- Trouver des solutions pour les problèmes non spécifiques à un module.

Une partie de ce qui suit est de la responsabilité de tout le groupe, mais il est bon de le rappeler ici:

Description textuelle et schéma décrivant l’architecture du système
- formalisme libre mais cohérent et légendé
Diagramme d’activité et/ou de séquence (temporel)
- Faisant apparaître les acteurs et actions
- Et les transitions avec leur(s) condition(s)
Description des interfaces entre modules (texte)
Dépot Git unique
- Avec la bonne structure de dossier
- Avec un commit par personne dans readme.txt

Plan de test global
- Liste des tests de fonctionalité, de performance, d’utilisabilité, d’acceptabilité… (tous les types de test be sont pas forcément pertinents pour votre projet)
- Pour chaque test
  - contexte de test
  - liste des entrées à fournir
  - liste des sorties attendus, avec la méthode de validation (est-ce qu’on attend exactement ce résultat au bit près, ou dans une certaine marge d’erreur, ou un résultat de cette forme…)
Squelettes de toutes les méthodes principales
- sous forme simulée
  - Fantôme : méthode vide utilisant System.out.println pour indiquer qu’elle est appelée.
  - Bouchon : méthode renvoyant toujours le même résultat.
  - Substitut : implémentation de la méthode très simplifiée.

rapport sur l’état de l’intégration des modules (quel module, quelle version, quels problèmes) dans le proto allégé
résultat des tests (passés, échoués, résultats quantitatifs/qualitatifs sur les performances, l’acceptabilité …) du proto allégé
Note: le rapport et les résultats se feront en utilisant les modules tels qu’implémentés, testés et livrés par les responsables des autres modules à une date à déterminer entre les responsables de modules. Il est acceptable qu’un livrable du module « test et intégration » ne contienne pas la dernière version d’un module (si ce dernier est en retard). Les retards seront cependant à justifier et feront l’objet d’une appréciation par le jury dans la notation de ces modules.
Note: l’encadrant va vérifier sur le dépôt Git que le code est documenté, lisible, maintenable, que tous les élèves ont contribué…