Tests unitaires servlets [fermé]

Question

J'ai un tas de servlets de l'exécution sous le conteneur de servlet Tomcat.Je voudrais séparer le code de test de code de production, j'ai donc envisagé d'utiliser un framework de test.JUnit est joliment intégré dans Eclipse, mais je n'ai pas réussi à le faire fonctionner à l'aide de servlets l'exécution d'un serveur Tomcat.Pourriez-vous s'il vous plaît recommander un framework de test unitaire qui prend en charge les tests de servlets Tomcat?Intégration Eclipse est sympa, mais pas nécessaire.

Answer 1

Découvrez ServletUnit, qui fait partie de HttpUnit.En un mot, ServletUnit fournit une bibliothèque d'objets fantaisie et utilitaires que vous pouvez utiliser dans l'ordinaire JUnit tests pour se moquer d'un conteneur de servlet et d'autres servlet liées à des objets comme des objets request et response.Le lien ci-dessus contient des exemples.

Answer 2

Le Framework Spring a nice prêt à se moquer des objets pour plusieurs classes de l'API Servlet:

http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/mock/web/package-summary.html

Answer 3

Ok.Ignorant la 'tomcat' bit et le codage de la servlet, votre meilleur pari est de créer des simulacres pour la réponse et demander des objets, et ensuite, dites-lui ce que vous attendez d'elle.

Donc, pour un norme vide doPost, et à l'aide de EasyMock, vous aurez

public void testPost() {
   mockRequest = createMock(HttpServletRequest.class);
   mockResponse = createMock(HttpServletResponse.class);
   replay(mockRequest, mockResponse);
   myServlet.doPost(mockRequest, mockResponse);
   verify(mockRequest, mockResponse);
}

Puis commencer à ajouter du code à la doPost.L'on se moque de échouent parce qu'ils n'ont pas d'attentes, et puis vous pouvez définir les attentes à partir de là.

Notez que si vous souhaitez utiliser EasyMock avec des classes, vous devrez utiliser le EasyMock classe de l'extension de la bibliothèque.Mais il va fonctionner de la même façon à partir de là.

Answer 4

Séparer les parties du code qui traitent les requêtes HTTP et de la réponse de la pièces que faire des affaires de la logique ou de la base de données de la manipulation.Dans la plupart des cas, cela va produire une architecture à trois niveaux, avec une base de données de la couche (pour la base de données et de persistance), le service de la couche (pour la logique métier) et une présentation de la couche (pour les requêtes et réponses HTTP).

1. Vous pouvez unité de tester les deux premières couches sans une servlet choses à tous;il sera plus facile de tester de cette façon.
2. Vous pouvez tester la couche de présentation, comme d'autres suggèrent, à l'aide de maquette HTTP objets request et response.
3. Enfin, si vous sentez que c'est nécessaire, vous pouvez faire des tests d'intégration à l'aide d'un trop comme Interface htmlunit ou JWebUnit .

Answer 5

Pour les "conteneur" de test, avoir un regard sur Cactus

Si vous voulez être en mesure de tester sans l'exécution d'un conteneur, vous pouvez simuler de ses composantes avec votre propre mockobjects (par ex.avec EasyMock) ou vous pouvez essayer MockRunner qui a de la "pré-défini" les Stubs pour les tests de servlets, jdbc, etc connexions.

Answer 6

Mise À Jour De Février 2018: OpenBrace Limitée a fermé, et son ObMimic produit n'est plus supporté.

Si vous voulez une nouvelle alternative à ServletUnit pour JUnit test de Servlets, vous pourriez trouver mon entreprise ObMimic bibliothèque utile.Il est disponible gratuitement sur le site de l' téléchargements page.

Comme avec ServletUnit, il fournit une bibliothèque de classes que vous pouvez utiliser dans la normale JUnit ou TestNG tests en dehors de toute conteneur de servlet pour simuler la Servlet API.

Son Servlet API objets n'ont aucun argument des constructeurs, sont entièrement configurables et inspectable pour tous les Servlet API des données et des paramètres, et une simulation complète de l'ensemble du comportement spécifié par la Servlet API javadoc.Pour aider à tester il y a le soutien pour l'enregistrement sélectif des appels de l'API Servlet, le contrôle de n'importe quel conteneur comportement dépendant, vérifie tout ambigu appels (c'est à direlorsque la Servlet API comportements n'est pas entièrement défini), et une mémoire JNDI de la simulation pour une servlet code qui repose sur JNDI recherches.

Pour plus de détails, d'exemples de code, guides, Javadoc, etc, voir le site web.