Construir una Aplicacion Web utilizando HttpUnit y la Metodología Diriga al Test

• Modificar la Aplicación
• Los Descriptores XML
• Reconstruir la Aplicación Web
• Poner a Prueba tu Aplicación

Modificar la Aplicación

 Los Descriptores XML

Aunque Ant ahora sabe lo que tiene que hacer, tu aplicación Web todavía no está preparada para desplegarse. Necesitas añadir cuatro ficheros al directorio src/WEB-INF: struts-config.xml, tiles-defs.xml, validation.xml, y web.xml. El descritor web.xml es obligatorio para todas las aplicaciones Web. Los otros tres descriptores XML los utiliza Struts.

Deberías obtener los cuatro ficheros del código de ejemplo: struts-config.xml.v1, tiles-defs.xml.v1, validation.xml.v1, y web.xml.v1. Copialos y renombralos como struts-config.xml, tiles-defs.xml, validation.xml, y web.xml, respectivamente:

• struts-config.xml
  El descriptor struts-config.xml configura el marco de trabajo Struts para formularios, accciones, controladores, mensajes y plug-ins. La versión uno de struts-config.xml es una espina que sólo configura el controlador, los ficheros de definición de mensajes de recursos, el plug-in Tiles y el plug-in Validator. El controlador es el panel central: todas las peticiones HTTP de acciones Struts pasan por él. El fichero de definición de mensajes de recursos almacena los textos para preguntas y errores para hacer más sencilla la internacionalizacion de la aplicación. El plug-in Tiles te permite componer varias páginas JSP en un sóla vista para mostrarla al usuario, de forma similar a como lo hacen los portales Web. El plug-in Validator te permite validar la entrada para asegurar que los formularios tienen los valores correctos.
• Descriptor tiles-defs.xml
  El descriptor tiles-defs.xml configura el plug-in Tiles con las páginas que mostrará la aplicación. Actualmente el fichero no tiene páginas, esencialmente es un shell vacío.
• Descriptor validation.xml
  El descriptor validation.xml configura el plug-in Validator con los tipos y formatos de los datos que quieres aceptar para los formularios de tu aplicación. Actualmente el fichero no contiene formularios, esencialmente es un shell vacío.
• Descriptor Web.xml
  El descriptor web.xml es el descriptor Web estándar especificado por el estándar J2EE. Tiene una estructura estándar bien definida. Puedes encontrar el DTD que define esta estructura en java.sun.com/dtd/web-app_2_3.dtd.

  En la versión uno del fichero web.xml suministrada en el código de ejemplo, se han configurado varios ítems:

  1. Se ha seleccionado el nombre de la aplicación como "Phone List Application". Este nombre lo utilizan herramientas que manejan WARs y herramientas que manejan las aplicaciones Web en ejecución en un contenedor servelt como Tomcat.
  2. Se ha definido y configurado el servlet Action de Struts. La definición del servlet nos permite referenciarlo posteriormente en este descriptor. La configuración activa y desactiva ciertas configuraciones y específica la localización de otros ficheros de configuración Struts en relación al directorio raíz del WAR.
  3. Se mapea el servlet Action que hemos definido préviamente para que maneje todas las URLs que terminen en ".do".
  4. Se ha configurado el timeout de sesión a 720 minutso (medio dia) para que no tengas que preocuparte de las pérdidas de sesiones debido a la inactividad (como los paros para comer). Esto debería modificarse a unv alor razonable como 10 ó 30 minutos en aplicaciones Web reales.
  5. Se configura la lista de ficheros de bienvenida para que las peticiones de directorios se comporten como si se hubiera añadido un nombre de fichero (por ejemplo, la petición de directory/foo/bar primero intentaría recuperar /foo/bar/index.jsp y /foo/bar/index.html, antes de mostrar el listado del directorio).
  6. Se definen las librerías de etiquetas que usarás en tu aplicación y especifica sus localizaciones. Las librerías de etiquetas permiten a los desarrolladores embeber etiquetas en las JSPs que llaman a código en clases Java, posiblemente con parámetros especificados como atributos en la etiqueta JSP o posible con datos contenidos dentro de la etiqueta. (Para más información sobre las librerías de etiquetas puedes consultar su especificación).

 Reconstruir la Aplicación Web

Para construir la aplicación Web, cambia al directorio ~/projects/phonelist,luego teclea Ant. Arranca Tomcat y despliega la aplicación tecleando ant deploy. Si todo va bien, deberías ver algo como esto en el fichero de log de Tomcat:

El log de Tomcat en la instalación por defecto está localizado en logs/localhost_log.2003-10-08.txt, excepto que 2003-10-08 se reemplaza con la fecha actual.

Ahora ejecuta el test tecleando ant test. Deberías ver el algo como esto:

El error es una indicación de que todavía no has configurado el código para manejar el URI /showList.do, que es lo que la clase del test le pide al servidor Web. Para corregir este problema necesitas escribir el código que permita a la aplicación Web pasar el test. Necesitas seguir los siguientes pasos:

1. Añade la sigiente sección para manageForm en la sección <form-beans> del ficheros struts-config.xml:

       <form-bean name="manageForm"
                  type="com.abcinc.phonelist.ManageForm"/>
   

   El formulario manageForm sigue la pista de los contactos que has seleccionado en la página show list y permite a la acción delete recuperar las selecciones.

2. Añade las secciones para /showList y /delete en la sección <action-mappings> de struts-config.xml:

       <action path="/showList"
               type="com.abcinc.phonelist.ShowListAction"
               name="manageForm"
               scope="request"
               validate="false">
         <forward name="success" path="showList"/>
       </action>
   
       <action path="/delete"
               type="com.abcinc.phonelist.DeleteAction"
               name="manageForm"
               scope="request"
               validate="true">
         <forward name="success" path="showList"/>
       </action>
   

   La acción /showList ejemplariza la clase ShowListAction y ejecuta su código, haciendo posible el reenvío de success, que apunta a una vista llamada showList. ShowListAction presumiblemente reenvía a success para poder mostrar los resultados generados.

   La acción /delete ejemplariza la clase DeleteAction y ejecuta su código, haciendo posible el reenvío de success, que apunta a una vista llamada showList. No tienes que implementar la clase DeleteAction, todavía. Pero si necesitas definir la acción /delete ahora, porque hemos especificado la acción /delete como atributo action para la etiqueta <html:form> en showList.jsp. Struts requiere que tengas al menos una definición en struts-config.xml por cada formulario que utilices en tus páginas JSP y que estén definidos con la etiqueta <html:form> de Struts.

3. Añade una sección para mainLayout en la sección <tiles-definitions> de tiles-defs.xml:

     <definition name="mainLayout" path="/mainLayout.jsp">
       <put name="titleString" value="Generic Title -- Change Me!" direct="true"/>
       <put name="body" value="Generic Content -- Change Me!" direct="true"/>
       <put name="bodyParam1" value="" direct="true"/>
     </definition>
   

   La definición de mainLayout es la plantilla base que podrán extender otras definiciones de vistas. Especificamente, las vistas que deriven de mainLayout pueden sobreescribir las variables titleString, body, y bodyParam1. Las vistas hijas también podrán introducir nuevas variables.

4. Añade una sección para showList en la sección <tiles-definitions> de tiles-defs.xml:

     <definition name="showList" extends="mainLayout">
       <put name="titleString" value="Phone List :: Show List"/>
       <put name="body" value="/showList.jsp"/>
     </definition>
   

   La definición de la vista showList desciende de la definición de mainLayout pero tiene un valor diferente para titleString y una página body distinta.

5. Copia ManageForm.java.v1 desde el archivo del código de ejemplo y ponlo en src/WEB-INF/classes/com/abcinc/phonelist como ManageForm.java. La clase ManageForm es una clase form de Struts. Este tipo de clases contienen datos de formularios y permiten a la aplicacion recuperar los datos fácilmente, de una forma orientada a objetos. Las clases form de Struts se adhieren al estándar JavaBean para métodos accesores y mutadores (métodos get y set, respectivamente).
6. Copia ShowListAction.java.v1 desde el archivo del código de ejemplo y ponlo en src/WEB-INF/classes/com/abcinc/phonelist como ShowListAction.java. La clase ShowListAction es una clase action de Struts. Este tipo de clases sirven como clases controladoras, en las que podemos pensar como paneles de mandos. Dirigen el flujo de control de la aplicación y algunas veces pueden realizar lógica de negocio de aplicaciones para pequeñas aplicaciones donde la escalabilidad no es un gran problema.

   Aunque es una forma poco elegante pero rápida, los datos de ejemplo también se configuran en la clase ShowListAction para poder tener algunos datos con los que trabajar. Idealmente pondríamos los datos de ejemplo en un fichero separado fuera de la aplicación Web para que no se desplieguen con la aplicación. El relleno de datos de ejemplo podría tratar simplemente con una base de datos e insertar los datos en una tabla vacía o casi vacía para probar. Por simplicidad, hay un método sucio y rápido de relleno de datos en la propia clase ShowListAction.

7. Copia mainLayout.jsp.v1 desde el archivo del código de ejemplo y ponlo en src/Web como mainLayout.jsp. La página mainLayout.jsp es la plantilla base para todas las demás páginas JSP de la aplicación. En grandes aplicaciones, tener una plantilla base de la que descienden todas las demás será mucho más útil y promoverá la consistencia y uniformidad entre todas las páginas de la aplicación.
8. Copia showList.jsp.v1 desde el archivo del código de ejemplo y ponlo en src/Web como showList.jsp. El fichero showList.jsp es una vista particular para una operación particular. Desciende de mainLayout.jsp. Muestra la lista de teléfonos de contacto. También contiene un formulario que permite al usuario seleccionar varios contactos para borrarlos. La razón de que la acción del formulario sea una URL parcial (/delete.do) en vez de una URL completa (http://localhost:8080/phonelist/delete.do) es porque Struts genera automáticamente la URL completa partiendo del path relativo (/delete.do). Sin embargo, esto es sólo si utilizas la etiqueta <html:form> de Struts para definir el formulario.
9. Copia ContactBean.java.v1 desde el archivo del código de ejemplo y ponlo en src/WEB-INF/classes/com/abcinc/phonelist como ContactBean.java. La clase ContactBean es un simple JavaBean que contiene las propiedades de un contacto. Proporciona un método conveniente para almacenar la información de un contacto y pasar dicha información entre las partes del código como una sola entidad.
10. Copia ContactDatabase.java.v1 desde el archivo del código de ejemplo y ponlo en src/WEB-INF/classes/com/abcinc/phonelist como ContactDatabase.java. La clase ContactDatabase es un sencillo almacenamiento en-memoria para ejemplares de ContactBean. Se utiliza ContactDatabase.java en vez de una base de datos relacional para mantener el ejemplo lo más simple posible.
11. Copia Sequence.java.v1 desde el archivo del código de ejemplo y ponlo en src/WEB-INF/classes/com/abcinc/phonelist como Sequence.java. La clase Sequence es un simple contador secuencial que permite generar valores ID únicos para los nuevos ejemplares de ContactBean.

Después de todos estos cambios, los descriptores struts-config.xml y tiles-defs.xml deeberían corresponderse con los struts-config.xml.v2 y tiles-defs.xml.v2 que hay en el archivo del código de ejemplo.

 Poner a Prueba tu Aplicación

Ahora prueba la versión revisada del código para ver si la aplicación pasa el test. Realiza los siguientes pasos:

1. Para Tomcat tecleando ./shutdown.sh en el directorio bin de la distribución de Tomcat.
2. Cambia al directorio de trabajo ~/projects/phonelist.
3. Teclea ant undeploy.
4. Teclea ant deploy.
5. Arranca Tomcat tecleando ./startup.sh en el directorio bin de la distribución de Tomcat.

Puedes probar la aplicación en http://localhost:8080/phonelist/showList.do. La aplicación debería mostrar una lista de contactos.

Vuelve al directorio ~/projects/phonelist y teclea ant test. Ahora se debería pasar el test showlist porque la URL que prueba contiene contenido y tiene cuatro o más filas en una tabla con el título Phone List.