TP réalisé à partir du lien suivant
RAPPELS FONDAMENTAUX ARQUILLIAN
Dans un test d’intégration san Arquillian, le serveur est démarré dans le code de test. Le test est donc DEPENDANT du serveur / conteneur (Ex : OpenEJB, Glassfish…)
Dans un test d’intégration avec Arquillien , le code de test n’est pas dépendant du serveur ! Le code créer dynamiquement une archive et la déploie dans un conteneur cible en fonction de l’adaptateur de conteneur disponible dans le classpath de test.
RAPPELS : 3 CARACTERISTIQUES CODE DE TEST INTEGRATION ARQUILLIAN :
1) une annotation @RunWith(Arquillian.class) sur la classe
2) Une méthode statique retournant une archive ShrinkWrap annotée avec @Deployment
3) Au mois une méthode annotée avec @Test
L’annotation @RunWith indique à JUnit d’utiliser Arquillian comme contrôleur pour le test.
Arquillian cherche alors une méthode statique annotée avec @Deployment pour récupérer l’archive de test (i.e. le micro-déploiement).
C’est là que l’effet magique se produit en faisant en sorte que toutes les méthodes @Test soient exécutées dans l’environnement du conteneur.
L’archive en question est définie à l’aide de ShrinkWrap, une API java pour générer des archives (i.e. jar, war, ear).
DEMO
TELECHARGEZ CECI
Dezippez. L’arborescence est la suivante
Arquillian choisit le conteneur cible en fonction de l’adaptateur de conteneur disponible dans le classpath de test.
DEMO1 : conteneur WEB embarqué
Le profil ‘arquillian-weld-ee-embedded’ positionne dans le CLASSPATH le conteneur Weld (disposant d’un adaptateur arquillian)
— > Lancez : mvn test -Parquillian-weld-ee-embedded
Expliquez
DEMO2 : conteneur externe Jboss 7
Le profil ‘arquillian-weld-ee-embedded’ positionne dans le CLASSPATH le conteneur Weld (disposant d’un adaptateur arquillian)
— > Lancez : mvn test -Parquillian-weld-ee-embedded
Expliquez