Le document présente un processus d'architecture pilotée par les tests (TDAP) visant à améliorer la qualité logicielle par des tests fonctionnels et techniques. Il décrit les typologies de tests, l'organisation d'un plan de test, ainsi que des exemples d'implémentation, en mettant l'accent sur la validation des exigences fonctionnelles et techniques. L'approche préconise une intégration efficace des tests dans le développement pour garantir la conformité et prévenir les régressions.

1. Augmenter la qualité par les tests XDT - TDAP Tests Driven Architecture Process AGnet SARL - 11 rue Robert Tourte 02190 Guignicourt - www.agnet.fr - Tél : 06 03 58 72 10 - contact@agnet.fr

2. Sommaire Les typologies de test Test unitaire fonctionnel Test unitaire technique Le plan de test Organisation des tests unitaires XDT - Tests Driven Architecture Process Démarche de pilotage par les tests Exemple d’implémentation avec HttpUnit

3. Les typologies de test Valider les règles fonctionnelles Conformité des processus métier (traitement et manipulation des données) Respect des règles d’alimentation et de présentation des données Valider les exigences techniques Respect de la performance attendue Sauvegarde et restitution conforme de l’état des données 2 typologies principales de tests Les tests fonctionnels Les tests techniques

4. Typologies de test Test unitaire fonctionnel Définition Représente l’exécution d’un scénario de cas d’utilisation Valide la conformité d’une ou plusieurs règles métier Déterminé depuis la description d’un cas d’utilisation issue du dossier de conception générale Description Utilise des données initiales de test précises (valorisation du modèle métier) Applique des règles fonctionnelles sur le modèle métier initialisé Contr ôle les états du modèle métier après exécution du scénario Valide ou invalide la conformité de l’implémentation du scénario Bonnes utilisations Pour valider des processus applicatifs ou métier (conformité d’implémentation d’un cas d’utilisation) Pour valider des règles de transformation de données (cohérence des valorisations d’un modèle métier)

5. Typologies de test Test unitaire fonctionnel Exemple de spécification d’un cas de test réalisant 3 scénarios de test pour valider la conformité d’un cas d’utilisation

6. Typologies de test Test unitaire technique Définition Teste les technologies d’intégration entre des composants applicatifs, métier et/ou techniques (ex : accouplement de services métier au moyen d’un annuaire, sauvegarde/restitution d’objets métier depuis un système de persistence) Déterminé depuis la description des exigences non fonctionnelles du dossier de conception générale (ex : bordereau d’un cas d’utilisation) Valide le respect des exigences de performance Description Réalise un ou plusieurs scénarios de test Utilise des données initiales de test précises Contr ôle la réalisation des processus non fonctionnels (ex : propagation d’événements entre des composants graphiques, accès à un annuaire, gestion des erreurs) Valide ou invalide la conformité de l’implémentation du scénario technique Bonnes utilisations Pour valider des assemblages de services (interractions entre des vues, gestion d’incidents techniques) Pour valider la conformité du système de sauvegarde/restitution des états du modèle métier Pour valider les exigences d’accès concurrentiels (volumétrie d’utilisateurs, délai de traitement)

7. Typologies de test Test unitaire technique Exemple de spécification d’un scénario de test d’indisponibilité du service de persistence pour le cas d’utilisation “Sauvegarder une commande” Le système sauvegarde la commande dans une base de données La base de données est indisponible Un message informe l’utilisateur de tenter une sauvegarde 2 minutes plus tard Le système alerte l’administrateur de base de données Scénario alternatif Le système sauvegarde la commande dans une base de données Un message confirmant la sauvegarde est présenté à l’utilisateur Scénario nominal Indisponibilté du système de persistance Exceptions Afficher un message de confirmation Post-conditions Prévisionnel de 2000 utilisateurs simultanés Volumétrie Délai maxi = 1 seconde Performance Sauvegarder une commande Cas d’utilisation

8. Le plan de test Organisation des test unitaires Packager les tests selon l’architecture de l’application testée (ex : couches, composants) Piloter les tests selon leur nature technique ou fonctionnelle Adopter une règle de nommage Par cas d’utilisation, créer un “UseCaseTest” Créer une méthode de test par scénario à tester pour valider la réalisation du cas d’utilisation

9. XDT - Tests Driven Architecture Process Les objectifs Obtenir rapidement du code opérationnel Disposer d’ indicateurs de suivi sur l’avancement du développement de l’application testée Indicateurs globaux : périmètres fonctionnel et technique testés/restant à tester Indicateur par couche ou composant : avancement du développement (tests en OK) de chaque composant Paralléliser la validation des exigences techniques et le développement des couches fonctionnelles Organiser la journée du développeur et définir des objectifs pour le lendemain (ex : “20 tests KO rouge à transformer en OK vert”) Priorisation des t âches selons les scénarios de test à terminer (implémentation des cas d’utilisation montrant des tests en KO) Identification rapide des implémentations à terminer Garantir la non-regression d’une application en cours d’évolution Les moyens Une démarche de construction d’application pilotée par les tests Des frameworks d’implémentation spécialisés pour développer des tests Frameworks dédiés à certaines couches (ex : pour tester des interfaces graphiques), technologies (ex : sur les ressources consommées) ou exigences (ex : sur la performance)

10. XDT - Tests Driven Architecture Process Démarche de pilotage par les tests Identifier les cas d’utilisation à tester Déterminer des scénarios pertinents et représentatifs à tester Définir les priorités de résolution du plan de test Créer la structure de l’application de tests Créer la structure de l’application cible et une implémentation initiale Chaque méthode applicative doit lever une exception “A implémenter” Réaliser le développement La mission du testeur “ Mettre à l’épreuve l’application cible ” : pour chaque classe de test et scénario p orté Implémenter les scénarios de tests en utilisant des données d’exemples Valorisation des données d’exemple pertinentes pour le scénario Déclenchement du cas d’utilisation testé avec les données d’exemple Contr ôle de la conformité de la réalisation du scénario -> EXECUTION ACTUELLE DU TEST = KO (levée d’exception “A implémenter”) La mission du développeur “ Transformer les KO en OK ” : pour chaque classe de l’application cible Implémenter le code réel pour résoudre le scénario Création ou enrichissement de l’implémentation du scénario conformément au dossier de spécification -> EXECUTION ACTUELLE DU TEST = OK

11. XDT - Tests Driven Architecture Process Exemple d’implémentation Coder un test fonctionnel avec HttpUnit et Junit sur l’utilisation de la couche web d’une application (simuler le déclenchement d’un cas d’utilisation par un utilisateur web) Déterminer les scénarios pertinents à tester Créer la structure du composant de test dédié à la couche web de l’application cible Créer la structure du servlet applicatif proposant le cas d’utilisation à l’utilisateur web et qui lève une exception “A implémenter” en implémentation initiale Implémenter le scénario de test avec des données d’exemple Contr ôler la conformité du résultat à l’exécution : le test est KO Implémenter le code réel du servlet applicatif pour résoudre le scénario et transformer le test en OK

12. XDT - Tests Driven Architecture Process Exemple d’implémentation Déterminer les scénarios pertinents à tester

13. XDT - Tests Driven Architecture Process Exemple d’implémentation 2. Créer la structure du composant de test dédié à la couche web de l’application cible

14. XDT - Tests Driven Architecture Process Exemple d’implémentation 3. Créer la structure du servlet applicatif proposant le cas d’utilisation à l’utilisateur web et levant initialement une exception “A implémenter”

15. XDT - Tests Driven Architecture Process Exemple d’implémentation Implémenter le scénario de test avec des données d’exemple 5. Contr ôler la conformité du résultat à l’exécution : le test est KO

16. XDT - Tests Driven Architecture Process Exemple d’implémentation 6. Implémenter le code réel du servlet applicatif pour résoudre le scénario et transformer le test en OK A chaque exécution des deux scénarios portés par le test, le résultat du test doit être OK

17. XDT - Tests Driven Architecture Process Adoptez une méthode pour tester vos applications Améliorez la qualité et réduisez le co ût de recettage d’une application nouvelle ou en évolution Anticipez la détection des “oublis” fonctionnels Validez rapidement les exigences techniques XDT - TDAP vous guide pour implémenter votre protocole de test Intégrer XDT - TDAP à votre processus de développement, c’est péreniser vos investissements en développement logiciel