TecnoRetales » Unit Test

Test-Driven Development

Manel Pérez Mata — Thu, 17 Sep 2009 08:50:56 +0000

Hace algún tiempo, os hablaba de la importancia de usar Unit Testing en nuestros desarrollos para tender localizados los posibles errores en cada una de nuestras funciones y, de ese modo, hacer un cambio en cualquier función no nos será crítico, ya que el test nos informará si la función está devolviendo los resultados esperados para cada cualquier.

Pero ¿y si al desarrollar el test me he dejado algún punto por comprobar? A menudo, tener una covertura del 100% resulta complicado debido al error humano, pero una vez detectado un error, debemos solventarlo y modificar el test para que no vuelva a darse ese error, y yendo un poco más allá, ¿por qué no pensar en los posibles errores que puede tener la función que desarrollemos antes de programarla? y ya que los hemos pensado, ¿por qué no realizar el test aunque todavía no hayamos desarrollado la función en questión? Pues precisamente, esa es la idea del Test-Driven Development (TDD a partir de ahora).

En resumen, podemos decir que el TDD es una práctica a la hora de programar que implica el desarrollo del test unitario antes de haber picado una sola línea del código de la función a testear… Pero, ¿qué ventajas tiene? ¿cuál es el workflow de esta práctica?

Ventajas de usar TDD

Generalmente, somos escépticos a la hora de adoptar una nueva práctica como el Unit Testing o más aún, algo que parece tan ilógico como TDD, pues es costoso en tiempo para el programador el desarrollo del test (cuando lo que nos gusta es desarrollar cosas útiles y no aparentemente inútiles como una prueba) e implica tener que pensar un rato antes de desarrollar. Sin embargo, seguir esta forma de programación tiene una serie de ventajas que hacen decantar la balanza a su favor:

Código de mayor calidad: El hecho de desarrollar el test antes que la función a ser testeada, nos obliga a pensar en como será la función, ordenarla y ver que errores podrá haber. Esto hará que en el momento de empezar a picar la función, tengamos muy claro que es lo que queremos hacer y como, por tanto, el código será más limpio y concreto.
Desacoplo del código: Cuando piensas en como será la función de manera que pueda ser testeada, te ves obligado a separar el bloque central en bloques más pequeños (que también serán testeados). De este modo, una función que podría ser muy compleja, acaba dividida en tres más pequeñas y fáciles de testear.
Disminución del tiempo de desarrollo: Independientemente del coste en tiempo de desarrollar el test (pues doy por hecho de que estás convencido de su utilidad y lo desarrollarás igualmente), el desarollo de la función es más rápida porque ya hemos pensado que y como lo vamos a hacer, simplemente hay que picarlo.
Disminución del número de líneas: TDD lleva implicita un proceso de refactorizando constante hasta que la función está acabada, gracias a eso, es fácil darnos cuenta que hemos complicado un proceso y lo podemos optimizar.

Workflow

Antes de comenzar el ciclo de trabajo se debe definir una lista de requerimientos. Luego se comienza el siguiente ciclo:

Elegir un requerimiento: Se elige de una lista el requrimiento que se cree que nos dará mayor conocimiento del problema y que a la vez sea fácilmente implementable.
Escribir una prueba: Se comienza escribiendo una prueba para el requerimiento. Para ello el programador debe entender claramente las especificaciones y los requisitos de la funcionalidad que está por implementar. Este paso fuerza al programador a tomar la perspectiva de un cliente considerando el código a través de sus interfaces.
Verificar que la prueba falla: Si la prueba no falla es porque el requerimiento ya estaba implementado o porque la prueba es errónea.
Escribir la implementación: Escribir el código más sencillo que haga que la prueba funcione. Se usa la metáfora “Déjelo simple” (”Keep It Simple, Stupid” (KISS)).
Ejecutar las pruebas automatizadas: Verificar si todo el conjunto de pruebas funciona correctamente.
Eliminación de duplicación: El paso final es la refactorización, que se utilizará principalemente para eliminar código duplicado. Se hacen de a una vez un pequeño cambio y luego se corren las pruebas hasta que funcionen.
Actualización de la lista de requerimientos: Se actualiza la lista de requerimientos tachando el requerimiento implementado. Asimismo se agregan requerimientos que se hayan visto como necesarios durante este ciclo y se agregan requerimientos de diseño (P. ej que una funcionalidad esté desacoplada de otra).

Resumiendo en una imágen:

PHPUnit – Tests Unitarios en PHP

Manel Pérez Mata — Thu, 14 May 2009 17:37:52 +0000

El otro día os hablaba de la importancia de usar test unitarios. Hoy os dejo un pequeño documento sobre PHPUnit, un framework para PHP que nos permite crear y ejecutar juegos de tests unitarios de manera sencilla, además de analizar por nosotros los resultados de los mismos.

Aunque inicialmente PHP empezó como complemento dinámico para pequeñas páginas web, actualmente PHP se utiliza para desarrollar aplicaciones web complejas, por lo que es importante poder realizar las pruebas pertinentes a nuestro código.

En la web oficial podemos ver todas las caractarísticas de PHPUnit, entre ellas encontramos:

* Puerto completo deJUnit para PHP5.
* Soporte para Mock Objects (jMock).
* Soporte para testeo de la base de datos
* Forma parte del grupo de frameworks de xUnit
* Almacena los resultados en una Test Database.
* Se integra con varias aplicaciones de test (como Selenium RC para aplicaciones web).

Instalar PHPUnit en Ubuntu

Podemos instalar este framework desde los repositorios oficiales de Ubuntu. Para ponerlo en marcha:

sudo apt-get update
sudo apt-get install phpunit

y ya lo tenemos en nuestra máquina. Generalmente PHPUnit se instala en la ruta /usr/share/php, dentro encontraremos una carpeta PHPUnit con el código del framework, además, se habrá instalado un script phpunit con el cual, podremos lanzar las pruebas desde línea de comandos.

Instalar PHPUnit con PEAR

Si lo deseamos, también podemos hacer una instalación con PEAR (PHP Extensión and Application Repository), que es un entorno de desarrollo y sistema de distribución para componentes de código.

Instalamos pear si no lo tenemos

sudo apt-get update
sudo apt-get install php-pear

Actualizamos a la última versión de pear
```
sudo pear upgrade pear
```
Por último, añadimos el canal desde donde encontraremos el código de PHPUnit al “repositorio” de pearl y lo instalamos
```
pear channel-discover pear.phpunit.de
# pear install phpunit/PHPUnit
```

Realizando nuestro primer test

Una vez lo tenemos instalado, haremos una prueba para asegurarnos de que funciona correctamente… para ello creamos un archivo FirstTest.php con la siguiente información:

class FirstTest extends PHPUnit_Framework_TestCase {
protected $fixture;
protected function setUp() {
// Create the Array fixture.
$this->fixture = Array();
}
public function testNewArrayIsEmpty() {
// Assert that the size of the Array fixture is 0.
$this->assertEquals(0, sizeof($this->fixture));
}
public function testArrayContainsAnElement() {
// Add an element to the Array fixture.
$this->fixture[] = ‘Element’;
// Assert that the size of the Array fixture is 1.
$this->assertEquals(1, sizeof($this->fixture));
}
}
?>

Nos situamos en el directorio en el que hemos creado el archivo y lo ejecutamos desde consola con:

phpunit FirstTest.php

Si todo ha ido bien, obtendremos un resultado por pantalla informándonos de que hemos pasado los tests de manera satisfactoria; algo similar a esto:

PHPUnit 3.0.6 by Sebastian Bergmann.

..

Time: 00:00

OK (2 tests)

Unit Test: La importancia de usar tests unitarios

Manel Pérez Mata — Mon, 11 May 2009 14:58:13 +0000

Un test unitario (Unit Test) es un trozo de código desarrollado con el único objetivo de verificar que una rutina o función de nuestro código está funcionando según esperamos.

En definitiva, lo que Unit Test pretende es tener trozos de código que se encargarán de testear por separado y de forma independiente cada uno de los métodos de las distintas clases que compongan el programa desarrollado, para que cuando se haga alguna modificación en el código, posibles errores derivados de esa modifiación puedan ser identificados y corregidos de manera rápida y eficaz.

La idea general que se destila de los tests unitarios es que si todas las partes de un código funcionan por separado, lo más probable es que el global que componen también funcione. Obviamente, siempre será necesario realizar un testeo general (o pruebas de integración) de la aplicación para comprobar que el todo que hemos compuesto funciona correctamente.

¿Porqué usar Unit Test?

Los más reticentes al desarrollo de tests os estareis preguntando… ¿Qué ventajas obtenemos de “perder tiempo” picando una serie de líneas de código que no están destinadas a hacer funcionar la aplicación?

Pues bien, estas pruebas aisladas proporcionan siete ventajas básicas:

Facilita los cambios en la aplicación ya que las pruebas nos asegurarán que los nuevos cambios no han introducido errores.
Simplifica la integración gracias a que permiten llegar a la fase de integración con un grado alto de seguridad de que el código está funcionando correctamente. De esta manera se facilitan las pruebas de integración.
Documenta el código. Las propias pruebas son un libro abierto sobre el funcionamiento de la función y los resultados esperados.
Separación de la interfaz y la implementación. Dado que la única interacción entre los casos de prueba y las unidades bajo prueba son las interfaces de estas últimas, se puede cambiar cualquiera de los dos sin afectar al otro.
Los errores están más acotados y son más fáciles de localizar: dado que tenemos preparado un test para cada función que puede desenmascararlo.
Aunque pueda parecer mentira, los test unitarios aceleran el desarrollo de nuestro software debido a que.
Ayuda a tener un código desacoplado gracias a que cada una de nuestras funciones está pensada para devolver un resultado que podrá ser testeado.