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

Ahora proceder�s a escribir tu tests, para la aplicaci�n de list�n telef�nico. Como vas a testear primero, escribe los tests antes de escribir el c�digo que implementa la funcionalidad. De esta forma, puedes estar m�s seguro de que tus test funcionan y de que la funcionalidad que vas a probar tambi�n funciona. Para poder testear, necesitas tener una idea b�sica de como funcionar� tu aplicaci�n. La aplicaci�n del list�n telef�nico tendr� dos p�ginas:

1. Una p�gina que muestre la lista de contactos con las propiedades b�sicas de cada contacto (Esta p�gina tambi�n te da la opci�n elegir un contacto para editarlo o elegir contactos para borrarlos).
2. Una p�gina que te permite introducir o editar los detalles de un contacto.

Escribe el test para la p�gina que muestra la lista de contactos. El test deber�a hacer un par de cosas:

1. Verificar que la p�gina "mostrar contactos" existe y devuelve alg�n contenido.
2. Verificar que la p�gina "mostrar contactos" muestra una lista de contactos o un mensaje diciendo que no hay contactos.

Ve al directorio ~/projects/phonelist/src/test/com/abcinc/phonelist/test y crea un fichero llamado ShowListTest.java. Inicialmente la clase ShowListTest se deber�a parecer a esta:

package com.abcinc.phonelist.test;

import junit.framework.TestCase;
import junit.framework.TestSuite;

public class ShowListTest extends TestCase {

  public static void main(String args[]) {
    junit.textui.TestRunner.run(suite());
  }

  public static TestSuite suite() {
    return new TestSuite(ShowListTest.class);
  }

  public ShowListTest(String s) {
    super(s);
  }
}

La clase contiene dos m�todos y un constructor. El m�todo est�tico main te permite ejecutar la clase desde la l�nea de comandos o desde un target de Ant <java>, que necesitaremos crear para poder realizar el testeo desde dentro de un target de Ant. El m�todo est�tico suite ejemplariza un objeto TestSuite, que se pasa al m�todo est�tico run de la clase TestRunner. Puedes ejemplarizar un objeto TestSuite con una subclase de TestCase o sin ella. Si le pasas un ejemplar de una subclase de TestCase, el constructor de TestSuite escanear� la clase buscando m�todos cuyos nombres empiecen por test y que no acepten argumentos. El objeto TestSuite ejecutar� autom�ticamente todos esos m�todos de la subclase de TestCase.

Ahora a�ade el test. Sit�a el siguiente m�todo despu�s del constructor ShowListTest:

  public void testShowList() throws Exception {
    WebConversation webConversation = new WebConversation();
    String url = protocol + "://" + hostname + ":" + port + path;
    WebRequest webRequest = new GetMethodWebRequest(url);
    WebResponse webResponse = webConversation.getResponse(webRequest);
    assertTrue("No content in phone list page", webResponse.getText().length() > 0);
    WebTable webTable = webResponse.getTableStartingWith("Phone List");
    assertNotNull("Phone List HTML table not found", webTable);
    assertTrue("Phone List table has less than 4 rows", webTable.getRowCount() >= 4);
  }

El m�todo testShowList realiza las siguientes acciones:

1. Env�a una petici�n GET de HTTP al servidor que hay en la localizaci�n especificada por un objeto String llamado url.
2. Obtiene la respuesta HTTP y la almacena en una variable.
3. Verifica que la respuesta contiene m�s de cero bytes de datos.
4. Verifica que la respuesta contiene una tabla HTML que tiene "Phone List" como su primer texto no blanco
5. Verifica que la tabla HTML que empieza con "Phone List" tiene al menos tres filas de datos.

Adem�s del c�digo para el m�todo testShowList, tambi�n necesitas a�adir algunas sentencias import para que se reconozcan las clases de HttpUnit que usas en testShowList. A�ade el siguiente c�digo debajo de las dos l�neas import junit:

import com.meterware.httpunit.GetMethodWebRequest;
import com.meterware.httpunit.TableCell;
import com.meterware.httpunit.WebConversation;
import com.meterware.httpunit.WebRequest;
import com.meterware.httpunit.WebResponse;
import com.meterware.httpunit.WebTable;

Observa tambi�n que el m�todo testShowList que acabas de teclear hace referencia a unas cuantas variables que no has declarado o definido: protocol, hostname, port, y path. Por eso, a�ade las siguientes l�neas encima de la declaraci�n del m�todo main pero dentro de la declaraci�n de la clase ShowListTest:

  private static String protocol = "http";
  private static String hostname = "localhost";
  private static int port = 8080;
  private static String path = "/phonelist/showList.do";

Ya tienes la clase ShowListTest, pero no podr�s compilarla o ejecutarlar porque el fichero build.xml no contiene instrucciones pertencientes a los tests. A�ade ahora esas instrucciones a build.xml. Primero, necesitamos definir una propiedad que especifique la localizaci�n del directorio de la distribuci�n de HttpUnit para poder acceder a los ficheros JAR que contienen las clases. A�ade esto al fichero build.xml justo despu�s de la l�nea que define la propiedad struts.install.dir, que est� localizada en la definici�n del tatget init:

    <property name="httpunit.install.dir" 
        value="/home/wchao/packages/httpunit-1.5.4"/>

Como ya es habitual, reemplaza el valor de la propiedad con la localizaci�n de este paquete en tu sistema. Como vas a complar clases Java que hacen uso de las librer�as de HttpUnit, necesitar�s incluir los ficheros de HttpUnit en el classpath. A�ade las siguientes l�neas al fichero build.xml justo despu�s de la l�nea que dice <property name="classpath" refid="base.path"/>:

    <path id="test.lib.path">
      <path refid="base.path"/>
      <fileset dir="${httpunit.install.dir}/lib">
        <include name="*.jar"/>
      </fileset>
      <fileset dir="${httpunit.install.dir}/jars">
        <include name="*.jar"/>
      </fileset>
    </path>

    <property name="test.lib.classpath" refid="test.lib.path"/>

M�s adelante usar�s la propiedad test.lib.classpath para proporcionar acceso a las librer�as de HttpUnit durante la compilaci�n de las clases de tests. Ahora a�ade, el siguiente target a build.xml justo despu�s del target llamado compile-classes:

  <target name="compile-tests" depends="init, create-unpacked-layout-dirs">
    <mkdir dir="${build.dir}/test"/>
    <javac destdir="${build.dir}/test"
           debug="on"
           deprecation="on"
           optimize="off"
           source="1.4">
      <src path="${src.dir}/test"/>
      <classpath path="${test.lib.classpath}"/>
    </javac>
  </target>

Este target compila las clases de tests localizadas en el directorio src/test del proyecto phonelist. Hace uso de la propiedad test.lib.classpath que acabas de definir para permitir que el compilador resuelva las referencias a las librer�as HttpUnit.

Ahora necesitas algunos targets para ejecutar los tests. A�ade el siguiente fragmento de XML al fichero build.xml justo despu�s de la definici�n del target deploy:

  <target name="test"
          depends="compile-tests, post-compile-tests-init, test-showlist"
          description="Run all tests"/>
  
  <target name="test-showlist" depends="compile-tests, post-compile-tests-init" 
        description="Run showlist test">
    <java classname="com.abcinc.phonelist.test.ShowListTest">
      <classpath path="${test.complete.classpath}"/>
    </java>
  </target>

Defines el target test para poder ejecutar todos los tests con un s�lo comando. Tendr�s que seguir a�adiendo atributos depends al arget test seg�n vayas a�adiendo m�s tests. El target test-showlist simplemente ejecuta el test showlist. Podr�as observar que los targets que acabas de definir tratan con un target y una propiedad que todav�a no existen (post-compile-tests-init y test.complete.classpath, respectivamente). En post-compile-tests-init, defines la propiedad test.complete.classpath para poder utilizarla como classpath en el target test-showlist. La raz�n por la que se define la propiedad test.complete.classpath de forma separada en post-compile-tests-init en vez de en el target init es que las clases de tests todav�a no se han compilado cuando se ejecuta el target init. Por lo tanto, definir un path que incluya clases de tests no funcionar� porque Ant espera definiciones de paths que existan. Por eso, se a�ade el target post-compile-tests-init. A�ade el siguiente c�digo XML al fichero build.xml despu�s del target compile-tests:

  <target name="post-compile-tests-init" depends="init">
    <path id="test.complete.path">
      <path refid="test.lib.path"/>
      <dirset dir="${build.dir}/test">
        <include name="**"/>
      </dirset>
    </path>
    <property name="test.complete.classpath" refid="test.complete.path"/>
  </target>

En este punto, tu fichero build.xml proporciona suficiente informaci�n para que Ant pueda realizar la construcci�n de la aplicaci�n Web. Tambi�n le has dicho a Ant que realice la construcci�n de los tests y que los ejecute.