ebook img

Impacts de l'AOP sur les tests dans un environnement Agile. Utilisation de Mocks pour les tests ... PDF

123 Pages·2013·2.38 MB·French
by  
Save to my drive
Quick download
Download
Most books are stored in the elastic cloud where traffic is expensive. For this reason, we have a limit on daily download.

Preview Impacts de l'AOP sur les tests dans un environnement Agile. Utilisation de Mocks pour les tests ...

Impacts de l’AOP sur les tests dans un environnement Agile Utilisation de Mocks pour les tests unitaires d’aspects Mémoire Félix-Antoine Bourbonnais-Bigras Maîtrise en informatique Maître ès sciences (M.Sc.) Québec, Canada © Félix-Antoine Bourbonnais-Bigras, 2013 Résumé Bienquel’AOPsoitprésentdanslepaysageinformatiquedepuisquelquesannées,sonadoption industrielle reste relativement timide malgré les bénéfices architecturaux promis et espérés. L’objectifprincipaldenostravauxestdefavoriserl’adoptiondel’AOPauprèsdesdéveloppeurs oeuvrant dans l’industrie. Nous voulons proposer des solutions adaptées qui permettent à ces professionnels d’embrasser l’AOP sans avoir à sacrifier leur processus, méthodologie et outils actuelsquileurpermettentd’atteindredesobjectifsdeperformance,dequalité,dedéploiement et de maintenabilité. Afin de nous permettre d’identifier des besoins réels, nous avons centré nos travaux sur des équipes employant un processus Agile. En effet, les processus Agiles préconisent généralement diverses pratiques et principes qui risquent d’être affectés par un changement de paradigme de programmation. C’est notamment le cas des tests qui tiennent une place très importante au sein des méthodes agiles, car ils permettent l’acceptation du changement sur le long terme. Dansunpremiertemps,nousavonsmenéuneétudeexploratoiredontl’objectifétaitdemieux définirquelsseraientlesirritantspourdesdéveloppeursdébutantsavecl’AOPetquitravaillent dans un environnement Agile. Àlalumièredesrésultatsdecetteétude,nousavonsamorcélapartiemaîtressedenostravaux qui consistent à élaborer une solution pour faciliter les tests unitaires d’aspects. Pour ce faire, nous avons conçu et rendu disponible un cadre d’applications (framework) permettant la création et le tissage de Mocks avec des aspects, facilitant ainsi l’isolation des aspects. Ce cadre a été développé de manière à s’arrimer avec les pratiques et outils répandus en industrie pour des équipes Agiles. iii Abstract AlthoughthefactthatAOPhasbeenproposedsincequiteafewyears,theindustrialadoption of this paradigm is not widespread in spite of the benefits hoped and promised for software architectures. The main goal of our work is to promote the adoption of AOP by industrial developers. We wanttoprovideadaptedsolutionsallowingthoseprofessionalstoembraceAOPwithouthaving to sacrifice their processes, practices and tools. We seek practical solutions to allow them to reach their performance, quality, deployment and maintainability goals. To better identify and understand the real needs of teams using Agile processes, our work is focus on Agile environments. In fact, Agile processes encourage numerous practices and principles that could be affected by the usage of AOP in such projects. For instance, this is the case for software testing who is largely embraced the Agile community as a way of sustaining the acceptation of change over time. Our first step was to conduct an exploratory study to identify what could be the irritants for Agile teams who want to use AOP for the first time. Consideringthoseresults,weundertookourmaincontributionconsistingtoproduceasolution tohelpunittestingofaspects.Todoso,wedevelopedandmadeavailableaframeworktocreate andweaveMockswithaspectstohelpisolateaspectsfortestingpurposes.Theframeworkwas designed to integrate easily with practices and tools commonly used in the industry by Agile teams. v Table des matières Table des matières vii Liste des figures xi 1 Introduction 1 1.1 AOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.4.1 Objectifs préalables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.4.2 Objectifs suite à l’étude . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.5 Méthodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.6 Structure du mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2 Notions préalables 9 2.1 Maintenabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2 Programmation orientée objet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.3 Programmation orientée aspect (AOP) . . . . . . . . . . . . . . . . . . . . . . . 11 2.3.1 Préoccupations et responsabilités . . . . . . . . . . . . . . . . . . . . . . 11 Responsabilité unique (SRP) . . . . . . . . . . . . . . . . . . . . . . . . 11 Préoccupations primaires et secondaires . . . . . . . . . . . . . . . . . . 11 Préoccupations transverses . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.3.2 Orientation aspect (AO) . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.3 AspectJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.3.4 Adoption dans l’industrie . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.4 Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.4.1 Valeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.4.2 Acceptation du changement . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.4.3 Pratiques de développement Agiles . . . . . . . . . . . . . . . . . . . . . 19 2.5 Tests dans un projet Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.5.1 Taxonomie des tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.5.2 Tests unitaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Isolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Procédure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.5.3 Mocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.5.4 Tests d’acceptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Tests d’acceptation dans le projet Mock4Aj . . . . . . . . . . . . . . . . 28 vii 2.5.5 Tests d’aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Tests unitaires d’aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.6 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.6.1 Support au développement dans un projet Agile . . . . . . . . . . . . . 30 2.6.2 Impacts sur l’environnement de développement . . . . . . . . . . . . . . 30 3 Évaluation des besoins 33 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.2 Travaux reliés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.3 Contexte de l’étude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.3.1 Le cours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.3.2 Le projet de session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.3.3 Les participants. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.3.4 Processus Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.3.5 Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.3.6 AOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.3.7 Formation des équipes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.3.8 Évaluations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.4 Analyse des résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.4.1 Contenu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.4.2 Étude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.4.3 Analyse statistique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.5 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.5.1 AOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Caractéristique de l’échantillon . . . . . . . . . . . . . . . . . . . . . . . 43 Satisfaction et pertinence . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Apprentissage et utilisation . . . . . . . . . . . . . . . . . . . . . . . . . 44 AspectJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.5.2 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Test de code Java conseillé . . . . . . . . . . . . . . . . . . . . . . . . . 45 Tests d’aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Utiliser des aspects pour tester . . . . . . . . . . . . . . . . . . . . . . . 45 3.5.3 Architecture et qualité . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.5.4 Réusinage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Réusinage d’aspects existants . . . . . . . . . . . . . . . . . . . . . . . . 46 Réusinage du code Java conseillé . . . . . . . . . . . . . . . . . . . . . . 46 3.5.5 Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Caractéristiques de l’échantillon . . . . . . . . . . . . . . . . . . . . . . . 46 Satisfaction concernant l’Agilité . . . . . . . . . . . . . . . . . . . . . . . 47 3.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4 Tests unitaires d’aspects à l’aide de Mocks 49 4.1 Motivations et objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.1.1 Problème initial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.1.2 Hypothèses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.1.3 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Solution intuitive et naturelle pour un développeur OO. . . . . . . . . . 52 Solution opérationnelle et facilement intégrable. . . . . . . . . . . . . . . 52 viii Solution extensible. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Convivialité (utilisabilité) . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.1.4 Démarche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.2 Démarche et approche menant à la solution . . . . . . . . . . . . . . . . . . . . 55 4.2.1 Parallèle entre les tests unitaires en OOP et AOP . . . . . . . . . . . . . 56 Tests unitaires d’objets . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Tests unitaires d’aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.2.2 Caractéristiques des tests unitaires d’aspects . . . . . . . . . . . . . . . 58 4.2.3 Utilisation de Mocks en AOP . . . . . . . . . . . . . . . . . . . . . . . . 59 Tester les comportements espérés et la logique. . . . . . . . . . . . . . . 59 Activation des comportement (exécuter un greffon) . . . . . . . . . . . . 60 Vérifier la portée (cibles) des points de coupure. . . . . . . . . . . . . . 60 4.2.4 Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.2.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Séparation des points de coupure et des greffons . . . . . . . . . . . . . 64 Couverture du test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 5 Mock4Aj : Solution proposée 67 5.1 Défis et innovation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 5.1.1 Isolation de l’aspect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 5.1.2 Tissage dans des classes générées . . . . . . . . . . . . . . . . . . . . . . 70 5.1.3 Simulation de contextes . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Exécution d’une méthode . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Appel d’une méthode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 5.1.4 Support du réusinage et des IDEs . . . . . . . . . . . . . . . . . . . . . . 78 5.1.5 Utilisation de l’API avec Java et d’autres technologies. . . . . . . . . . . 79 5.2 Détails techniques de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . 79 5.2.1 Survol des composantes . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Implémentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 5.2.2 Tissage d’objets dynamiques . . . . . . . . . . . . . . . . . . . . . . . . 82 API offert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Implémentation utilisant AspectJ . . . . . . . . . . . . . . . . . . . . . . 82 5.2.3 Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Pourquoi utiliser des Proxies . . . . . . . . . . . . . . . . . . . . . . . . 84 Fonctionnement des Proxies . . . . . . . . . . . . . . . . . . . . . . . . . 85 API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Implémentation avec CGlib . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.2.4 Simulation d’appels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Sélection de la méthode ciblée . . . . . . . . . . . . . . . . . . . . . . . . 91 Simulation de l’appel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 6 Conclusion 95 A Liste des User Stories pour Mock4Aj 99 B Code source pour Mock4Aj 103 ix Bibliographie 105 x

Description:
We seek practical solutions to allow them to reach their Agile teams who want to use AOP for the first time. Considering those results and weave Mocks with aspects to help isolate aspects for testing purposes. 5.1 Diagramme de séquence démontrant l'impossibilité de tester une primitive « call
See more

The list of books you might like

Most books are stored in the elastic cloud where traffic is expensive. For this reason, we have a limit on daily download.