Analyses Automatiques pour le Test de Programmes
Orientés Aspect

Analyse de l’impact des aspects sur les cas de test

Lors du test d’un programme orienté aspect, deux stratégies sont possibles. La première consiste à tester le programme dans sa globalité, c’est-à-dire avec les aspects. Une seconde stratégie consiste à tester le programme de manière incrémentale, en commençant par le programme de base. Nous nous plaçons dans le cas où le programme de base est testé d’abord, puis les aspects sont ajoutés. L’avantage de cette solution est que le programme de base est plus testable que le programme entier. Le programme de base est plus petit que le programme entier : il y a moins de méthodes, pas d’aspects et donc moins de couplage. Aussi, le programme de base est un programme orienté objet normal et est a priori plus testable qu’un programme orienté aspect comme vu précédemment. Il existe deux problèmes avec cette stratégie. D’abord, si les aspects introduisent trop de changements à trop d’endroits différents, la majorité des cas de test écrits pour le programme de base aura besoin d’être réécrite, ce qui entraîne un surcoût trop important. Ensuite, même si les changements ne sont pas trop nombreux il reste difficile d’identifier les cas de test qui doivent prendre en compte ces changements. Concernant le nombre de changements introduits par les aspects, nos études ont montré, voir Chapitre 2, que le nombre de points de jonction sélectionnés est très faible pour une majorité des expressions de point de coupe. La stratégie proposée semble donc raisonnable, car on peut s’attendre à ce qu’une grande partie des cas de test pour le programme de base puisse être réutilisée pour le programme avec aspects. Le second problème nécessite une solution adaptée. Par exemple, dans le cas de la vente aux enchères, on peut écrire le cas de test présenté sur le Listing 3.1. Ce cas de test crée deux utilisateurs (un vendeur et un acheteur). Le vendeur met en vente un objet à un prix minimum de 30 e, et l’acheteur enchérit 40 e. Ensuite le cas de test termine la vente et vérifie que le montant de la vente, dans ce cas 40 e, a bien été transféré du compte de l’acheteur vers le compte du vendeur. Si on ajoute l’aspect AltBid (voir Section 1.1.2, page 13) dont un extrait est présenté sur le Listing 1.1, page 15, le montant de la vente devient le montant de la deuxième meilleure enchère (ou l’enchère minimum   public class TestAuction { 2 @Test 3 public void testClose() { 4 User buyer = new User(…); 5 buyer.getAccount.add(40); 6 User seller = new Buyer(…); 7 Auction auction = new Auction(seller, »description »,30); 8 auction.open(); 9 auction.placeBid(buyer,40); 10 auction.close(); 11 assertEquals(40, 12 seller.getAccount().getBalance()); 13 assertEquals(0, 14 buyer.getAccount().getBalance()); 15 } 16 } Listing 3.1 – Exemple de cas de test pour la classe Auction s’il n’y a qu’une enchère) plus 10 %. Donc dans le cas de test, le montant de la vente n’est plus 40 e, mais 33 e. Le cas de test qui passait avant, ne passe plus après l’introduction de l’aspect, puisque l’assertion de la ligne 11 n’est pas validée. Cet échec est dû au fait que l’aspect a modifié le flot de données de la méthode Bid.getAmount, en modifiant la valeur de retour. Pourtant le cas de test n’exécute pas directement Bid.getAmount. Cet impact des modifications du flot de contrôle ou du flot de données sur les cas de test est difficile à détecter, et vérifier individuellement chaque cas de test peut être très coûteux. Afin d’identifier automatiquement les cas de test nécessitant d’être adaptés ou supprimés et les cas de test pouvant rester inchangés, nous proposons une analyse statique de l’impact des aspects sur les cas de test. Le but de cette analyse est d’identifier les cas de test qui peuvent exécuter un greffon tissé dans le programme de base. Une des particularités de la programmation orientée aspect est qu’il est possible de connaître statiquement où un greffon est tissé, et donc quelles sont les modifications apportées par un aspect. Dans un premier temps nous identifions les méthodes où des greffons ont été tissés ; ces méthodes sont dites impactées. Ensuite, grâce à une analyse statique des cas de test, nous déterminons quels sont les cas de test qui peuvent exécuter ces méthodes impactées ; ces cas de test sont dit impactés. Une analyse statique évite l’exécution des cas de test non-impactés. Les cas de test non-impactés ne sont affectés par aucun effet de bord introduit par des aspects. Le résultat de ces cas de test ne change donc pas avec l’introduction des aspects, et il n’est donc pas nécessaire des les exécuter. Si ces cas de test non impactés sont nombreux, ne pas les exécuter peut faire gagner beaucoup de temps. L’analyse statique permet   aussi d’effectuer l’analyse sur un programme qui n’est pas complet ou qui comporte des fautes empêchant l’exécution normale du programme. Nous avons implémenté l’analyse d’impact dans un outil nommé Vidock, disponible sur Internet 1 . Vidock est une extension pour l’environnement de développement Eclipse. L’analyse s’intègre parfaitement à l’environnement en s’exécutant de manière transparente pour l’utilisateur. Dans ce chapitre nous détaillons l’analyse statique proposée. La Section 3.1 détaille la façon dont les méthodes impactées puis les cas de test impactés sont sélectionnés. Puis la Section 3.2 décrit comment l’analyse a été implémenté. Enfin la Section 3.3 montre avec de cas d’étude, l’intérêt de l’analyse statique proposée. 3.1 Sélection des cas de test impactés Nous proposons une analyse d’impact afin de déterminer quels sont les cas de test impactés par l’introduction d’aspects. Cette analyse permet de distinguer les cas de test ne nécessitant ni d’être modifiés ni d’être exécutés des cas de test nécessitant une attention particulière lors du re-test du programme après l’introduction d’un aspect. Cette analyse est implémentée dans l’outil Vidock. Vidock analyse d’abord l’expression de point de coupe et sélectionne l’ensemble des méthodes impactées par un aspect. Ensuite, Vidock analyse les cas de test et sélectionne l’ensemble des cas de test impactés. Vidock s’appuie sur AJDT 2 (Aspectj Development Tools), un outil de développement pour AspectJ, et sur Spoon [Pawlak 06], un outil d’analyse statique pour Java. La Figure 3.1 présente une vue d’ensemble du processus. D’abord, Vidock récupère des informations de AJDT et de Spoon. Puis, il sélectionne toutes les méthodes où au moins un aspect est tissé (a). Ces méthodes sont appelées méthodes impactées. Parallèlement, Vidock construit un graphe d’appels statique (SCG, Static Call Graph) pour chaque cas de test ((b) et (c)). Finalement, Vidock calcule l’ensemble des cas de test impactés, en recoupant l’ensemble des méthodes impactées et les graphes d’appels statiques (d). 

Sélection des méthodes impactées

La première partie de l’analyse statique sélectionne les méthodes impactées par le tissage d’aspects. La sélection des méthodes est divisée en deux étapes, (1) nous récupérons l’ensemble des points de jonction sélectionnés par les expressions de point de coupe (réalisé par AJDT), et ensuite (2) nous calculons l’ensemble des méthodes où se trouvent ces points de jonction (réalisé par Vidock). La sélection des méthodes impactées par les aspects pose deux problèmes. Il faut gérer les expressions de point de coupe dynamiques, et il faut déterminer la méthode correspondant à un point de jonction. 1http://www.irisa.fr/triskell/Softwares/protos/vidock/ 2http://www.eclipse.org/ajdt/  code source Cas de test AJDT Spoon getAmount getAmount (a) (b) (c) getAmount (d) (e) sélection des méthodes impactées construction des graphes d’appels sélection des cas de test impactés cas de test impactés Vidock FIG. 3.1 – Vue d’ensemble du processus. CHAPITRE 3. ANALYSE D’IMPACT 63 Expressions de point de coupe dynamiques Les expressions de point de coupe dynamiques sont des expressions de point de coupe avec une partie dynamique. Toutes les expressions de point de coupe ont une partie statique qui sélectionne un certain nombre de points de jonction correspondant à des positions dans le code source. La partie dynamique d’une expression de point de coupe ajoute une contrainte qui doit être vérifiée dynamiquement pour que le greffon soit exécuté. L’ensemble effectif de points de jonctions est donc inclus dans l’ensemble de points de jonction sélectionnés par la partie statique. Le Listing 1.1 montre un exemple d’expression de point de coupe dynamique, getAmount. Cette expression de point de coupe sélectionne les appels à la méthode Bid. getAmount effectués dans le flot de contrôle de la méthode Open.close. La condition d’exécution du greffon dépend du flot d’exécution, et n’est donc pas calculable statiquement. Il est même possible que le même appel à Bid.getAmount soit sélectionné dans un cas de test mais pas dans un autre. Il faut donc faire une sur-approximation. AJDT fait une sur-approximation de l’ensemble des points de jonction en ne considérant que la partie statique de l’expression de point de coupe. Formellement, cette sur-approximation peut être décrite comme suit. Soit P un programme, C l’ensemble de toutes les expressions de point de coupe déclarées dans P, et J l’ensemble de tous les points de jonction. Soit fpc : C → P(J) la fonction qui retourne l’ensemble des points de jonction sélectionnés par une expression de point de coupe. Soit fsur : C → P(J) la fonction qui retourne la sur-approximation de l’ensemble des points de jonction. ∀c ∈ C, fpc(c) ⊆ fsur(c) Dans le cas où l’expression de point de coupe est statique, fpc = fsur. La Figure 3.2 illustre cette sur-approximation. L’expression de point de coupe getAmount (A) sélectionne l’ensemble de points de jonctions fpc(A) = Jd. Comme vu précédemment, il est impossible de calculer Jd statiquement. L’expression de point de coupe statique B sélectionne un ensemble de points de jonctions fpc(B) = Js plus grand, tel que Jd ⊂ Js. En pratique, l’ensemble calculé par AJDT est fsur(A) = Js. Association d’une méthode à un point de jonction Le second problème pour l’analyse statique de l’impact d’un aspect est la sélection effective des méthodes impactées. Une méthode impactée est une méthode liée à un point de jonction sélectionné par une expression de point de coupe. La spécification de la sélection des méthodes impactées est décrite ci-dessous Soit M l’ensemble des méthodes dans un programme P. Soit g : J → M la fonction qui à tout point de jonction associe la méthode liée.