Diseño ágil con TDD

Capítulo 5. Tests unitarios y frameworks xUnit

En capítulos previos hemos citado xUnit repetidamente pero xUnit como tal no es ninguna herramienta en sí misma. La letra x es tan sólo un prefijo a modo de comodín para referirnos de manera genérica a los numerosos frameworks basados en el original SUnit.

SUnit fue creado por Kent Beck para la plataforma SmallTalk y se ha portado a una gran variedad de lenguajes y plataformas como Java (JUnit), .Net (NUnit), Python (PyUnit), Ruby (Rubyunit), PHP (PHPUnit), Perl (PerlUnit), C++ (CppUnit), etc.

Si aprendemos a trabajar con NUnit y PyUnit como veremos en este libro, sabremos hacerlo con cualquier otro framework tipo xUnit porque la filosofía es siempre la misma. Además en Java, desde la versión 4 de JUnit, se soportan las anotaciones por lo que NUnit y JUnit se parecen todavía más.

Una clase que contiene tests se llama test case (conjunto de tests) y para definirla en código heredamos de la clase baseTestCase del framework correspondiente (con JUnit 3 y Pyunit) o bien la marcamos con un atributo especial (JUnit 4 y NUnit).

Los métodos de dicha clase pueden ser tests o no. Si lo son, serán tests unitarios o de integración, aunque podrían ser incluso de sistema. El framework no distingue el tipo de test que es, los ejecuta a todos por igual. Quienes debemos hacer la distinción somos nosotros mismos, una vez que tenemos claro qué queremos probar y por qué lo hacemos con un framework xUnit.

En este capítulo todos los tests son unitarios. En próximos capítulos veremos cómo escribir también tests de integración. Para etiquetar los métodos como tests, en Java y .Net usamos anotaciones y atributos respectivamente. En Python se hace precediendo al nombre del método con el prefijo test (ejemplo: def test_letter_A_isnot_a_number) igual que pasaba con la versión 3 de JUnit.

Los métodos que no están marcados como tests, se utilizan para unificar código requerido por ellos. Es normal que haya código común para preparar los tests o para limpiar los restos su ejecución, por lo que xUnit provee una manera sencilla de organizar y compartir este código: los métodos especiales SetUp y TearDown. SetUp suele destinarse a crear variables, a definir el escenario adecuado para después llamar al SUT y TearDown a eliminar posibles objetos que no elimine el recolector de basura.


Copyright (c) 2010-2013 Carlos Ble. La copia y redistribución de esta página se permite bajo los términos de la licencia Creative Commons Atribución SinDerivadas 3.0 Unported siempre que se conserve esta nota de copyright.