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

123 Pages·2013·2.38 MB·French

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