Discussion :

[teletexte]

Bonjour à tous,

Je pose une question :

Quelle est à la bonne pratique pour faire des tests unitaires avec Spring sachant que :

• J'utilise l'aop (pour les logs par exemple)

• Je fais l'injection via spring des beans utilisés dans mes tests

• Mes classes implements des interfaces

?

Exemple :

Je fais une classe A implémentant une interface IA et un ATest sur A.
ATest utilise A (Type A déclacré et non IA pour tester toutes les méthodes) et A est injecté par Spring.

Le soucis est que vu que je fais de l'aop dans A, j'ai un proxy donc j'ai un problème d'injection (org.springframework.beans.factory.BeanNotOfRequiredTypeException: Bean named 'a' must be of type [A], but was actually of type [$Proxy40]).

Ok, plutôt que d'utiliser jdk dynamic, je peux utiliser cglib pour mes tests, mais le soucis c'est A est parametré et cglib n'a pas l'air de le supporter (java.lang.ClassCastException: java.lang.Class cannot be cast to java.lang.reflect.ParameterizedType)

Donc au secours, comment faire ?

[ray_fab]

Bonjour, la première chose à faire pour toi c'est d'avoir ces 2 annotations sur la ta classe de Test:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations={"classpath: test.xml"})

où test.xml désigne le fichier qui déclare tes beans, ici il se trouve dans le classpath de ton application.
La seconde chose c'est pas utiliser l'implémentation pour ton test mais l'interface, si tes coupes sont exécutées avec avec l'interface ce que je te propose même, tu n'auras aucun soucis à te faire avec les Proxy. Mais oublie de mettre l'annotation Autowired sur l'instance de ton interface déclarée dans la classe de test. ce qui est important avec les Proxy JDK dynamiques, c'est qu'ils peuvent te créer les proxys automatiques, raison pour laquelle leurs utilisation est presque incontournable; et c'est cglib qui fait une très bonne implémentation du JDK dynamique, donc si tu les utilises tu devrais avoir aucun soucis à te faire avec l'AOP.
J'espère que je t'ai apporté une solution.

[teletexte]

Merci pour ton retour.

Pour ce qui est des annotations, je les utilise déjà.

Oui effectivement avec les interfaces ça marche, normal les proxys implémentent les interfaces. Sauf que je peux pas tester les méthodes propres à l'implémentation... Et un test c'est propre à un implémentation... ou peut être pas !??

[ray_fab]

En fait si ta classe implémente une interface, les proxy s'occuperont uniquement de l'interface. Mais dans ta classe d'aspect tu es à mésure d'avoir l'instance de ta classe d'implémentation soit en utilisant l'argument target, ou la méthode getTarget de la classe ProceedingJoinPoint ou JoinPoint selon ta coupe. Je ne vois pas pourquoi t'insiste d'avoir l'instance de la classe d'implémentation dans ta classe de test. Quand tu as une coupe sur une interface cela signifie que tout ce que tu dois faire ailleurs que dans la classe d'aspect ne doit concerner uniquement l'interface, le reste doit se faire dans la classe d'aspect. En fait si tu veux faire de la programmation orientée aspect, cela signifie que tu veux une autre politique de gestion des préocupations transversales, cela signifie que seule l'interface et ses méthodes seront appelées ailleurs que dans la classe d'aspect. En plus si je comprends bien tu veux juste gérer des log avec ton aspect, donc utilises la classe d'apect pour exécuter toutes les méthodes de ta classe d'implémentation et ailleurs utilises l'interface. sinon une dernière proposition serat de créer des parents, mais je vois pas l'interêt vu que tu as déjà une solution simple à partée de la main.

[ray_fab]

Et un test c'est propre à un implémentation... ou peut être pas !??

Si tu as décidé d'avoir une interface cela signifie que le test doit être propre à l'interface et non à l'implémentation. sinon il faut faire une classe de test spéciale pour l'implémentation qui ne va pas se soucier de ta classe d'aspect.