¿Cómo probar un archivo jsp?

12

Estoy desarrollando una aplicación Java 6 EE y estoy probando mi código jsp con otro con una versión de prueba de las llamadas de función y el código utilizado en el original, pero parece suelto y poco práctico. ¿Hay una buena manera de realizar este tipo de pruebas?

testing programming-practices unit-testing java-ee zamancer
fuente
2
¿Qué necesitas saber de las pruebas?

Respuestas:

15

Si no ha leído sobre MVC (modelo de controlador de vista), hágalo. No debe tener código en un JSP, solo mostrar. Poner código en JSP es muy de 1900.

En serio, si no hay código en el JSP, no estás probando el JSP. Estás probando la acción / flujo. Entonces podrías usar HttpUnit o Selenium . La gran diferencia es que Selenium prueba desde un navegador real.

Jeanne Boyarsky
fuente
13

No creo que haya una buena manera de probar los JSP, principalmente porque se desarrollaron antes de que las pruebas unitarias se convirtieran en un foco de desarrollo.

Robert Martin escribió un artículo hace varios años sobre cómo hackear el compilador JSP para que pueda dirigir pruebas unitarias no basadas en contenedores. Su idea era buena, pero se rompió con el próximo lanzamiento principal de TomCat. Simplemente hay demasiada magia sucediendo.

No estoy de acuerdo con la idea de "simplemente no agregue código y no tendrá que probarlo". OBVIAMENTE no deberías poner código en el JSP. Sin embargo, una IU compleja a menudo tendrá una lógica de visualización que podría probarse de forma rentable.

Considere este ejemplo:

<c:choose>
  <c:when test="${mydto.showAdminMenu}">
   The admin menu....
  </c:when>
  <c:otherwise>
    Something completely different
  </c:otherwise>
</c:choose>

Este código ya está bien factorizado: la lógica para decidir si mostramos el menú de administración no está en la vista. Sin embargo, si hubiera una manera fácil de probar los JSP unitarios, entonces podríamos escribir una prueba para mostrar que el comportamiento que queremos realmente aparece, y nos protegería de un cambio en la página que accidentalmente hizo visible el menú de administración cuando no debería. 't be.

portabella
fuente
4

Existe un programa (utilizado por cualquier servidor de aplicaciones que esté utilizando) que compila un archivo .jsp en un archivo .java. Por ejemplo, la versión jspc de sun / oracle .

Una vez que tenga el .java que produciría la traducción .jsp (incluso puede considerar usar esto como parte del proceso de compilación, precompilar el jsp para mejorar el rendimiento en el primer hit), luego puede ejecutar pruebas contra él burlándose de la solicitud y verificando que la respuesta es lo que espera.

(editar con ejemplo :)

El método clave para esto es el _jspService(HttpServletRequest, HttpServletResponse)método.

Un trivial hola mundo jsp:

<html>
    <head>
        <title>Hello world</title>
    </head>
    <body>
        <h1>Hello world</h1>
        Today is: <%= new java.util.Date().toString() %>
    </body>
</html>

(test.jsp ubicado dentro de un directorio llamado 'webapp' y también un directorio 'out') Cuando se compila con el comando jspc -v -d out -compile -uriroot webapp/ test.jspcoloca en un directorio out un archivo llamado test_jsp.java. Este archivo tiene dentro (junto con un poco de otra configuración):

  public void _jspService(HttpServletRequest request, HttpServletResponse response)
        throws java.io.IOException, ServletException {

    PageContext pageContext = null;
    HttpSession session = null;
    ServletContext application = null;
    ServletConfig config = null;
    JspWriter out = null;
    Object page = this;
    JspWriter _jspx_out = null;
    PageContext _jspx_page_context = null;

    try {
      response.setContentType("text/html");
      pageContext = _jspxFactory.getPageContext(this, request, response,
                null, true, 8192, true);
      _jspx_page_context = pageContext;
      application = pageContext.getServletContext();
      config = pageContext.getServletConfig();
      session = pageContext.getSession();
      out = pageContext.getOut();
      _jspx_out = out;

      out.write("<html>\n\t<head>\n\t\t<title>Hello world</title>\n\t</head>\n\t<body>\n\t
\t<h1>Hello world</h1>\n\t\tToday is: ");
      out.print( new java.util.Date().toString() );
      out.write("\n\t</body>\n</html>\n\n");
    } catch (Throwable t) {
      if (!(t instanceof SkipPageException)){
        out = _jspx_out;
        if (out != null && out.getBufferSize() != 0)
          try { out.clearBuffer(); } catch (java.io.IOException e) {}
        if (_jspx_page_context != null) _jspx_page_context.handlePageException(t);
      }
    } finally {
      _jspxFactory.releasePageContext(_jspx_page_context);
    }
  }
}

En este punto, es una comprobación para asegurarse de que se llama a JspWriter con write o print y que el contenido de la llamada es lo que espera que sea.

Dicho todo esto, en un mundo ideal, uno no debería tener ninguna lógica dentro del jsp; dicha lógica estaría en el controlador o en taglibs que se prueban con otras técnicas.


fuente
1
¿Qué habría en el JSP que sería probado / burlado? ¿Configurando datos en la solicitud / sesión y luego verificando la pantalla? ¿O es esto si no se siguen las buenas prácticas y hay una lógica real en el JSP?
Jeanne Boyarsky
@JeanneBoyarsky Actualizado con ejemplo jsp y código. No consideraría una buena práctica intentar probar esto con un junit tradicional, es otro ámbito de prueba. La profundidad de la burla podría ser incómoda dependiendo del conjunto de herramientas (por ejemplo, subclasificar JspWriter para que uno pueda probar fácilmente lo que se le envía).
3

También puede considerar usar un marco de prueba de unidad HTTP como HTTPUnit | http://httpunit.sourceforge.net/ .

Otro punto importante es separar bien las preocupaciones de su aplicación.

Por ejemplo, utilizando técnicas como TDD (http://en.wikipedia.org/wiki/Test-driven_development), diseñará tipos para la comprobabilidad.

Los tipos consumidos dentro de JSP se probarán en pruebas unitarias específicas. Si esto no es posible, debe simular la interacción usuario -> navegador (nuevamente, HTTPUnit o herramienta similar).

gsscoder
fuente
2
  • intente externalizar el código funcional del servlet para probarlo fuera de un contexto de servlet con pruebas unitarias reales
  • pruebe los puntos finales del servlet con herramientas como:
    • HTTPUnit
    • HtmlUnit
    • Selenio
    • Cactus
    • JspTest
    • ...
haylem
fuente