FitNesse
FitNesse es una herramienta colaborativa para el desarrollo de software. Permite a los clientes, testers, y programadores aprender lo que su software debería hacer, y automáticamente compara lo que realmente hace. Compara las expectativas de los clientes a los resultados reales.
Contenido
Algunas Caracteristicas
FitNesse es una herramienta de pruebas de software. Desde otra perspectiva, FitNesse es un framework de código abierto que hace que sea fácil para los equipos de software:
- Colaborativamente definir Pruebas De Aceptacion - páginas web que contienen tablas simples de entradas y los resultados esperados.
- Ejecutar dichas pruebas y ver los resultados
FitNesse es una wiki.
- Se puede fácilmente crear y editar páginas.
FitNesse es un servidor web.
- No requiere ninguna configuración o instalación.
- Simplemente ejecute y luego dirigir su navegador a la máquina donde se está ejecutando.
Ejemplo de Uso
Vamos a trabajar con el paradigma de BDD y como hacerlo con FitNesse.
Asi como hicimos con Concordion, tomamos el proyecto que creamos en el Curso de Introducción al desarrollo Java EE. Donde necesitamos hacer un servicio que, dado un id de provincia, devuelva la provincia en cuestión. El contrato de negocio dice que:
* si se invoca con un id existente, se devuelve la provincia correspondiente * si se invoca con un id inexistente, se devuelve null * si se invoca con un null, se tira una java.lang.IllegalArgumentException
Paso a paso para empezar con FitNesse
1. Obtener la última versión de la página oficial. Nosotros lo hicimos con la versión fitnesse20090214.
2. Desempaquetar la versión en el equipo que se decida usar como servidor y ejecutar el archivo run.bat que se encuentra en el empaquetado.
3. Estamos listos para desde el browser conectarnos a fitness: http://localhost/FitNesse.
Como podemos implementar FitNesse en un proyecto
4. Escribir la página que represente el proyecto, dentro del framework.
Si trabajamos con Scrum, son las historias las que van dando forma al proyecto. Por cada historia tenemos que tener claro su definición de terminado.
La página, por ejemplo, puede contener una tabla por historia, que resuma el criterio de aceptación acordado por el grupo. Es el acuerdo al que se llega entre desarrolladores, tester, dueño del producto y analista de negocio.
Supongamos que se trata de la historia "Consulta de Provincia":
Como se puede ver:
- A la página, le ponemos el nombre del proyecto a testear
- La tabla lleva por título el nombre de la historia que nos ocupa
- Anteponemos a la tabla una breve descripción de la historia
- El parámetro id será el que recibirá el método nombreProvincia, que inicialmente no apunta a ninguna parte, y cuando la historia esté terminada, tendrá que estar funcionando
- Inicialmente, solo sabemos que tendrá que construirse un test que contenga el método nombreProvincia. Eso quedará indicado con el signo "?".
En términos de proyecto:
- Tenemos que definir donde quedarán compiladas las clases de nuestros test de aceptación
- Necesitamos definir el path con las librerias del servidor de aplicaciones, en nuestro caso, GlassFish
- Necesitamos definir el path del jar de seguridad del servidor de aplicaciones
- Necesitamos indicar el jar que genera el proyecto a probar
En términos de wiki:
!define TEST_SYSTEM {slim}
!define COLLAPSE_SETUP {true} !define COLLAPSE_TEARDOWN {true}
!path /workspace/jee001-workshop-dosideas/dosideas-ejb/build/test/classes !path /workspace/jee001-workshop-dosideas/lib/GlassFishClient/* !path C:/Archivos de programa/glassfish-v2ur2/lib/javaee.jar !path /workspace/jee001-workshop-dosideas/dosideas-ejb/dist/dosideas-ejb.jar
|import| |com.dosideas.business.ejb.provincia|
!|Consulta De Provincia| |id|nombreProvincia?| |1|Buenos Aires| |99|null|
5. Ahora, todos tenemos documentado el caso de prueba de la historia.
6. Una vez terminado el desarrollo, todos podemos demostrar el comportamiento de la historia.
El background del framework FitNesse
Al haber creado una página para el proyecto, en el servidor donde está ejecutándose el framework nos vamos a encontrar con:
- un directorio con el mismo nombre de la pagina, guardando el historial de versiones de la wiki
- un directorio de log, conteniendo un subdirectorio por cada pagina que creamos. En cada subdirectorio, un archivo content.txt con información de log de ejecución de los test de esa página.
Por lo que sería una buena práctica que el nombre de la página lleve el nombre del proyecto. Y en esa página se diseñe un test suite. Tambien puede pasarnos que necesitemos crear una pagina por proyecto-módulo, por ejemplo.
El background de los test de aceptacion
Los test de aceptación que van cubriendo las tablas de la wiki de FitNesse pueden ser construidos en un proyecto aparte. Aunque por cuestiones de versionado, mantenimiento y orden, una buena práctica puede ser la de incluir un paquete de test de aceptación en el mismo proyecto objeto de los test.
Y así, en el paquete de test de aceptación, ir agregando los paquetes de acuerdo a los componentes que serán testeados desde FitNesse.
Para el ejemplo que tenemos, hicimos una clase ConsultaDeProvincia.java que contiene el método nombreProvincia. En este caso, y en términos de componentes java, estaremos instanciando el EJB que dado un id, provee el nombre de la provincia:
public class ConsultaDeProvincia {
private Long id; private ProvinciaSessionRemote instance;
public void setId(Long id) {
this.id = id;
}
public String nombreProvincia() throws NamingException {
InitialContext initialContext = new InitialContext();
Object provinciaObject = initialContext.lookup("ejb/ProvinciaSessionBean");
instance = (ProvinciaSessionRemote) PortableRemoteObject.narrow
(provinciaObject, ProvinciaSessionRemote.class);
Provincia provincia = instance.buscarProvinciaPorId(id);
return provincia == null ? null : provincia.getNombre();
}
Un poco más
- plugin de control de versión: git
- integración contínua: hudson
