Une bonne stratégie pour tester Spring Framework de bout en bout

Question

Il s'agit donc d'une question plutôt "vaste", mais ce que j'essaie de faire est le suivant :

J'ai une application Spring, MVC, JDBC (MySQL) et JSP qui tourne sur tomcat.

Mon objectif est de tester l'ensemble de la "pile" à l'aide d'une méthode appropriée.

Pour l'instant, Junit utilise Selenium pour simuler l'interaction d'un utilisateur réel avec l'application (ce qui nécessite un compte fictif), et effectue différentes validations, par exemple pour voir si un élément est présent dans la page, si la base de données contient une valeur spécifique ou si une valeur correspond à celle de la base de données.

La première préoccupation est que cela utilise réellement la base de données et qu'il est donc difficile de tester certains scénarios. J'aimerais vraiment pouvoir simuler la base de données. Il faut qu'elle émule des configurations de comptes spécifiques, des états de données, etc.

La deuxième préoccupation est que, étant donné que j'utilise ce qui se trouve dans la base de données et que les données changent continuellement, il est difficile de prédire le comportement et, par conséquent, d'affirmer correctement

J'ai regardé Spring Test mais il permet de tester en dehors d'un conteneur de servlet, donc pas de JSP et pas de test Javascript possible.

J'ai vu la documentation de DBUtils mais je ne suis pas sûr qu'elle puisse m'aider dans ce cas.

J'aimerais donc demander à mes collègues développeurs de me donner des conseils pour.. :

• Exécuter des tests selenium sur une base de données simulée
• Autoriser des configurations différentes par test
• Maintien de la compatibilité avec Maven/Gradle

Answer 1

J'ai commencé par mettre en place une fonction de câblage automatique commandé pour prendre en charge ce type de dérivation.

C'est une idée que j'ai reprise du framework Seam avec lequel j'ai travaillé par le passé mais je n'ai pas trouvé d'équivalent dans Spring.
L'idée est d'avoir une annotation de précédence (fw, app,mock,...) qui sera utilisée pour résoudre l'implémentation actuelle d'un bean autowired. C'est déjà facile en xml mais pas avec la configuration java.

Nous avons donc notre référentiel normal de haricots avec la priorité sur l'application et un paquet de test qui reprend ces classes avec la priorité sur les simulacres. Si les deux sont dans le classpath, Spring devrait normalement échouer avec une exception de duplicate bean found. Dans notre cas, la beanfactory étendue prend simplement le bean avec la plus haute priorité.

Je ne suis pas sûr que l'annotation d'ordre de Spring puisse être utilisée directement, mais je préférais de toute façon avoir des portées de préséance "bien définies", afin que nos développeurs sachent clairement de quoi il s'agit.

! Bien qu'il s'agisse d'une approche intéressante pour tester les so beans, je ne l'utiliserais pas pour remplacer la définition d'une base de données, mais plutôt pour utiliser une base de données en mémoire comme hsql, comme l'ont déjà mentionné certaines réponses précédentes. !