Servlets de test unitaire

Question

J'ai un lot de servlets qui s'exécutent sous le conteneur de servlet Tomcat. Je voudrais séparer le code de test du code de production, donc j'ai envisagé d'utiliser un framework de test. JUnit est bien intégré dans Eclipse, mais j'ai échoué à le faire exécuter des servlets en utilisant un serveur Tomcat en cours d'exécution. Pourriez-vous recommander un framework de test unitaire prenant en charge le test des servlets Tomcat? L'intégration d'Eclipse est agréable mais pas nécessaire.

Answer 1

Découvrez ServletUnit, qui fait partie de HttpUnit. En un mot, ServletUnit fournit une bibliothèque de mocks et d'utilitaires que vous pouvez utiliser dans les tests JUnit ordinaires pour simuler un conteneur de servlet et d'autres objets liés aux servlets comme les objets de requête et de réponse. Le lien ci-dessus contient des exemples.

Answer 2

OK. En ignorant le bit "tomcat" et en codant le servlet, le mieux est de créer des mocks pour les objets de réponse et de requête, puis de lui dire ce que vous en attendez.

Donc, pour un doPost vide standard et en utilisant EasyMock, vous aurez

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

ensuite commencer à ajouter du code à la doPost. Les simulacres échoueront parce qu'ils n'ont pas d'attentes, et vous pourrez alors définir les attentes à partir de là.

Notez que si vous souhaitez utiliser EasyMock avec des classes, vous devez utiliser la bibliothèque d'extensions de classe EasyMock. Mais ça marchera de la même manière à partir de là.

Answer 3

Pour « en conteneur » test, un coup d'oeil à Cactus

Si vous voulez être en mesure de tester sans un conteneur en cours d'exécution, vous pouvez simuler ses composants avec vos propres mockobjects (par exemple avec EasyMock) ou vous pourrait essayer MockRunner qui a des stubs "pré-définis" pour tester les servlets, jdbc-connexions etc.

Answer 4

Le framework Spring a de beaux objets fantaisie prêtes à l'emploi pour plusieurs classes sur l'API Servlet:

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

Answer 5

Séparer les parties de ce code qui traitent des requêtes HTTP et la réponse des parties qui font des affaires manipulation logique ou de base de données. Dans la plupart des cas, cela produira une architecture à trois niveaux, avec une couche de données (pour la base de données/persistance), une couche de service (pour la logique métier) et une couche de présentation (pour les requêtes et réponses HTTP).

1. Vous pouvez tester les deux premières couches sans aucune tâche de servlet; il sera plus facile de tester de cette façon.
2. Vous pouvez tester la couche de présentation, as others suggest, en utilisant des objets de requête et de réponse HTTP fictifs.
3. Enfin, si vous pensez qu'il est vraiment nécessaire, vous pouvez effectuer des tests d'intégration en utilisant un HtmlUnit ou JWebUnit.

Answer 6

Mise à jour février 2018: OpenBrace Limited has closed down, et son produit ObMimic n'est plus supporté.

Si vous souhaitez une alternative plus récente à ServletUnit pour le test JUnit des servlets, vous pouvez trouver la bibliothèque ObMimic de ma société utile. Il est disponible gratuitement à partir de la page downloads du site.

Comme pour ServletUnit, il fournit une bibliothèque de classes que vous pouvez utiliser dans des tests JUnit ou TestNG normaux en dehors de tout conteneur de servlet pour simuler l'API Servlet. Ses objets API Servlet ont des constructeurs sans argument, sont entièrement configurables et inspectables pour toutes les données et tous les paramètres pertinents de l'API Servlet, et fournissent une simulation complète de tout le comportement spécifié par javadoc de l'API Servlet. Pour faciliter les tests, l'enregistrement sélectif des appels API Servlet est pris en charge, contrôle tout comportement dépendant du conteneur, vérifie les appels ambigus (c'est-à-dire où le comportement de l'API Servlet n'est pas entièrement défini) et une simulation JNDI en mémoire code de servlet qui repose sur les recherches JNDI.

Pour plus de détails, un exemple de code, des guides "comment", Javadoc etc, consultez le site Web.