Es típico que los programadores verifiquemos un algoritmo través del depurador del entorno de desarrollo. Ejecutando paso a paso podemos ir comprobando el valor de la variables, y verificando así que cada variable toma el valor adecuado en cada momento. Este es un proceso lento y complicado, ya que requiere mucha atención del programador, para ir comprobando todas las variables, y es muy fácil perderse en algún detalle o equivocarse en alguna operación. Además, el proceso de depuración requiere mantener la atención al máximo durante mucho tiempo, y yo, no soy capaz de mantener ese nivel de concentración durante un proceso de depuración largo, de por ejemplo, una o dos horas.
Otra opción es desarrollar un pequeño programa que utilice la unidad que estamos probando. Una ventana con un botón, o un programa de consola, desde el que vamos codificando “lo que se nos ocurre”, para ir viendo que todo funciona correctamente: llamadas a funciones o métodos, pruebas con casos “raros”, usos típicos... una vez que hemos visto que funciona, lo típico es desechar el programa.
El último enfoque, y el más acertado, es el diseño y programación de pruebas unitarias, a través de “Casos de pruebas” y “Colecciones de pruebas”.
La pruebas unitarias son pequeños módulos auxiliares, que se encargan de verificar el funcionamiento de otras unidades lógicas del sistema.
Una “Colección de Pruebas” (Test Suite) es un conjunto de pruebas que hacemos sobre una unidad lógica. Si, por ejemplo, tenemos una unidad que hace operaciones matemáticas, deberíamos hacer sobre ella varias pruebas: una que compruebe que sume bien, otra que divida bien, otra que verifique que es capaz de manejar números negativos o decimales, etc. Cada una de estas pruebas individuales la llamaremos un “Caso de Prueba” (Test Case).
La forma de programar las pruebas es sencilla: simplemente basta con hacer una serie de llamadas a las funciones que queremos verificar, utilizando para ello valores conocidos en sus parámetros. Después comprobaremos que el valor retornado por la función es el que esperábamos, y si la función ha hecho algún cambio global (crear ficheros, cambios en base de datos, etc.), comprobaremos que estos cambios son los esperados. Más adelante veremos un ejemplo concreto.
Las colecciones de pruebas se debe mantener junto con el código fuente, para ir ampliándola según se amplía la unidad. Por ejemplo, si aparece un nuevo método público, tendremos que modificar la colección de pruebas, para hacer un nuevo caso de prueba. Cada vez que aparezca un nuevo bug, debemos realizar un nuevo caso de prueba que verifique que el bug no ha vuelto a aparecer, simulando todos los pasos necesarios para reproducirlo.
Los gurús de la Programación eXtrema y en general de las metodologías de desarrollo guiado por pruebas (TDD: Test Driven Development), recomiendan desarrollar las pruebas unitarias antes que la propia unidad. La principal razón de esto es muy sencilla: durante la programación, pasamos por muchas fases de investigación y descubrimiento de nuestras propias necesidades. Muy pocas veces desarrollamos algo con el conocimiento absoluto de lo que queremos conseguir y a dónde queremos llegar, sino que este conocimiento se va adquiriendo mientras escribimos el código. Si programamos las pruebas antes, vamos definiendo cómo queremos utilizar la unidad, qué queremos pasarle como parámetros de entrada y qué nos gustaría que nos respondiese como salida, en definitiva: el conocimiento que se obtiene durante la programación. Lo más habitual es ir adquiriendo este conocimiento durante la vida del proyecto, mejorándolo poco a poco en cada una de las iteraciones (o versiones). Sin embargo, si lo primero que hacemos es programar las pruebas, conseguimos este conocimiento antes de desarrollar el producto, por lo que una vez que hemos terminado las pruebas, ya sabemos lo suficiente como para programar la unidad de una forma mucho más rápida y consistente que de la otra forma.
