J'ai vu la jetty a une classe de servlettes de servlettes que vous pouvez utiliser pour tester des servlets.
tester = new ServletTester(); tester.setContextPath("/"); tester.addServlet(TestServlet.class, "/servlet/*"); ... tester.start();
3 Réponses :
Jetez un coup d'œil à Jakarta Cactus P>
Cactus est un cadre de test simple pour le code Java Server Server (Servlets, EJBS, Tag Libs, Filtres, ...). p> blockQuote>
FYI Jakarta Cactus a été obsolète depuis 2011/08/05. :(
Je n'ai jamais trouvé d'avantages à tester des servlets directement (ni d'actions de Struts, disons), en particulier compte tenu du travail nécessaire pour le faire. p>
La plupart de mes servlets / actions / Peu importe les pojos pour la majeure partie de leur travail et les pojos sont fortement testés. Les webapps eux-mêmes ont des suites de tests HTMlunit. Tout, entre, je suppose être juste plombrage. P>
Je ne crois pas que j'ai même rencontré une sorte de bug qui aurait seulement été pris en testant directement les classes de servlet et qui ne seraient pas capturées par les tests Pojo ou WebApp. P>
Point pris. Cependant, dans mon cas, j'ai hérité d'un servlet indésirable qui est terriblement complexe et buggy. Être capable de l'appeler à partir d'un test unitaire pour le scénario spécifique qui échoue aura grandement raccourcir mon processus de débogage. :)
Pour les tests d'unités, cela ne doit pas compter sur le conteneur de servlet que vous utilisez. Ceci est similaire à l'utilisation de HSQL au lieu d'Oracle pour le test unitaire du code d'accès à la base de données. Donc, même si vous écrivez pour un déploiement Tomcat, si la jetée est plus appropriée pour les tests d'unités (plus rapides de démarrage, plus facile à configurer, etc.), vous pouvez aller avec jetée.