Servlets de prueba unitaria [cerrado]

Question

Tengo un montón de servlets ejecutándose en el contenedor de servlets de Tomcat.Me gustaría separar el código de prueba del código de producción, así que consideré usar un marco de prueba.JUnit está muy bien integrado en Eclipse, pero no pude ejecutar servlets usando un servidor Tomcat en ejecución.¿Podría recomendar un marco de prueba unitario que admita la prueba de servlets Tomcat?La integración de Eclipse es buena pero no necesaria.

Answer 1

Verificar Unidad de servlet, que forma parte de HttpUnit.En pocas palabras, ServletUnit proporciona una biblioteca de simulacros y utilidades que puede usar en pruebas JUnit ordinarias para simular un contenedor de servlets y otros objetos relacionados con servlets, como objetos de solicitud y respuesta.El enlace de arriba contiene ejemplos.

Answer 2

Spring Framework tiene bonitos objetos simulados listos para usar para varias clases de la API de Servlet:

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

Answer 3

Bueno.Ignorando el bit 'tomcat' y codificando el servlet, lo mejor que puede hacer es crear simulaciones para los objetos de respuesta y solicitud, y luego decirle qué espera de ello.

Entonces, para un doPost vacío estándar y usando Fácil Mock, tendras

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

Luego comience a agregar código al doPost.Los simulacros fracasarán porque no tienen expectativas, y luego puedes configurar las expectativas a partir de ahí.

Tenga en cuenta que si desea utilizar EasyMock con clases, deberá utilizar la biblioteca de extensión de clases EasyMock.Pero a partir de ese momento funcionará de la misma manera.

Answer 4

Separe las partes de ese código que se ocupan de las solicitudes y respuestas HTTP de las partes que se ocupan de la lógica empresarial o la manipulación de la base de datos.En la mayoría de los casos, esto producirá una arquitectura de tres niveles, con una capa de datos (para la base de datos/persistencia), una capa de servicio (para la lógica empresarial) y una capa de presentación (para las solicitudes y respuestas HTTP).

1. Puede realizar una prueba unitaria de las dos primeras capas sin ningún tipo de servlet;Será más fácil probar de esa manera.
2. Puedes probar la capa de presentación, como otros sugieren, utilizando objetos de solicitud y respuesta HTTP simulados.
3. Finalmente, si cree que es realmente necesario, también puede realizar pruebas de integración utilizando un método como Unidad HTML o Unidad JWeb .

Answer 5

Para pruebas "en contenedor", consulte Cactus

Si desea poder realizar pruebas sin un contenedor en ejecución, puede simular sus componentes con sus propios objetos simulados (p. ej.con Fácil Mock) o podrías intentar corredor simulado que tiene códigos auxiliares "predefinidos" para probar servlets, conexiones jdbc, etc.

Answer 6

Actualizado en febrero de 2018: OpenBrace Limited ha cerrado, y su producto ObMimic ya no es compatible.

Si desea una alternativa más nueva a ServletUnit para pruebas JUnit de Servlets, puede encontrar la de mi empresa. Obmímica biblioteca útil.Está disponible de forma gratuita en el sitio web. descargas página.

Al igual que ServletUnit, proporciona una biblioteca de clases que puede usar en pruebas normales de JUnit o TestNG fuera de cualquier contenedor de servlet para simular la API de Servlet.

Sus objetos Servlet API tienen constructores sin argumentos, son completamente configurables e inspeccionables para todos los datos y configuraciones relevantes de Servlet API y proporcionan una simulación completa de todo el comportamiento especificado por el javadoc de Servlet API.Para ayudar con las pruebas, hay soporte para la grabación selectiva de llamadas a la API de Servlet, control sobre cualquier comportamiento dependiente del contenedor, comprobaciones de llamadas ambiguas (es decir,donde el comportamiento de la API de servlet no está completamente definido) y una simulación JNDI en memoria para cualquier código de servlet que dependa de búsquedas JNDI.

Para obtener detalles completos, código de ejemplo, guías prácticas, Javadoc, etc., consulte el sitio web.