7
Je travaille sur une application Java EE 6. Quand j'ai commencé, j'écrivais des tests pour mes classes EJB en instanciant manuellement l'EJB, puis en ajoutant manuellement les membres qui étaient normalement fournis par injection de dépendance. Comme l'application devient plus compliquée, je trouve que cette approche ne suffit pas de le couper. Je voudrais donc pouvoir démarrer mon propre conteneur EJB dans le framework de test, afin qu'il puisse gérer mes beans. Quelle est la meilleure façon d'aborder cela? J'ai entendu parler de javax.ejb.embeddable.EJBContainer, y at-il d'autres options?Stratégies de test EJB?
(j'utilise Glassfish 3, et construire avec Maven, si cela fait une différence.)
Évidemment, tester les POJO est plus facile. Mais je ne peux pas sortir toute la logique de mes EJB et dans des classes autonomes - si je pouvais faire cela, je n'utiliserais pas les EJB en premier lieu. Agir comme un client EJB contre un conteneur en cours d'exécution est une bonne description de ce que j'essaie de faire, j'essaie juste de trouver la meilleure façon d'y parvenir. –
Je pense que vous aviez raison de tester l'application déployée. J'ai essayé de faire fonctionner EJBContainer pour moi (en utilisant glassfish-embedded comme implémentation), j'ai fait beaucoup de cerceaux pour que la persistance fonctionne, puis j'ai fini quand je me suis rendu compte qu'un service de minuteur EJB (dont mon application dépend en plusieurs endroits) n'a pas été fourni. Je me suis rendu compte que même si je réussissais à mettre en place une sorte de moteur pour exécuter mes EJB, il ne reproduirait jamais TOUTES les conditions dans un vrai conteneur, donc ce serait un test inutile. –
'Rappelez-vous qu'il n'y a pas de règle qui stipule que les tests unitaires automatisés ne peuvent pas nécessiter un système en cours d'exécution. Eh bien, il existe des règles et ces tests ne sont pas des tests unitaires par définition :) –