Integración continua. Cuando lanzar las pruebas

¿Cuando se deben lanzar las pruebas automáticas? Existen muchas tendencias en función de un factor:

- Numero de cambios de código (Cada cuantos cambios de código se lanzan las pruebas):

• Ante cualquier cambio: Tiene la ventaja de que se detectan mejor los fallos pero tiene la desventaja de que puede relentizar el desarrollo ya que hace que el programador se centre demasiado en las pruebas.
• Ante cambios en una funcionalidad: Tiene la ventaja de favorecer el desarrollo pero si la funcionalidad es muy grande se corre el riesgo de no hacer las pruebas lo suficientemente buenas.
• ....

Como se ve a medida que se amplia el ratio se gana en velocidad de desarrollo y se pierde en calidad de pruebas.

- Tiempo (se establece un tiempo periodo de ejecución para lanzar las pruebas)

• Cada dia: Son pruebas bastante periódicas y pueden detectar un fallo antes. Lo malo es que es un tiempo fijo y corto y puede no tener en cuenta los ciclos de desarrollo (como un sprint de SCRUM)
• Cada fin de semana: al ser mas tiempo es mas facil que se alinien con los ciclos de desarrollo pero se tarda mas en detectar un fallo.
• ...

Como se ve a medida que se amplia el ratio se gana en alinear las pruebas con ciclos de desarrollo y se pierde en detección temprana de errores.

-...

Hay muchas tendencias y dentro de cada tendencia hay diversas opciones que pueden mejorar y empeorar un factor u otro. Es una locura entonces cual elegir. La mejor elección es no tener en cuenta los factores si no la que obtiene mejor resultado. Lo que sede hacer es elegir una tendencia y dentro de la tendencia elegir una opción, darle un tiempo y ver que resultados se obtienen. Si son malos resultados entonces probar con otra hasta que se de con la opción y la tendencia que mejor se ajuste al equipo y al tipo de producto.

Por que merece la pena arreglar las pruebas automaticas

Cuando se hacen pruebas automaticas sobre un software tiene el GRAN (e histórico) problema de que al modificar el software se debe modificar las pruebas automaticas y eso siembre se ha visto como una perdida de tiempo y un handicap para no hacer pruebas automaticas.

El problema es el enfoque, tener que adaptar la prueba automatica implica:

• Conocer como funciona la prueba (lo cual permite mejorar y ampliarla).
• Probar de una manera distinta a como lo hace el programador y tener mas exito en la busqueda de errores.
• Ya que se tiene que adaptar la prueba, se pueden crear nueva.

Se le debe dar este enfoque para que los programadores no tengan el problema de verlo inútil y aburrido. ¿Como se hace mas ameno una prueba? No haciéndola muy simple. Un ejemplo muy bueno es el siguiente:

1) Se cambia el parametro de la funciona suma de int suma (int a, int b) a int suma (int a, int b, int c).

2) Se le pide a un programador que lo cambie en 100 ficheros. 

Esto es aburrido y frustrante.

Sin embargo, si la prueba automatica tiene mas magnitud el programador lo vera de otra manera. Ejemplo,

1) Se cambia la interface web donde el usuario suma ahora 3 valores y no dos

2) Se pide al programador que cambie la petición html que prueba la pagina web que por debajo llama a la nueva funcion int suma (int a, int b, int c).

3) Ademas se le pide medir tiempos, aumentar las pruebas a 10000 iteranciones, etc..

Esto es mas desafiante y seguro que prueba mas el software que una simple prueba para llamar a un método.

El otro gran motivo es que al automatizar las pruebas siempre se descrubren errores de plantemaiento ya que te obliga a mirar el codigo desde otra perspectiva. Es decir, se pueden encontrar fallos despues de la famosa frase del programador: "yo he probado todo y funciona"

Problema con la filosofia Test Driven Development

Una de las mejores filosofías, al menos en teoria, para el desarrollo de software es la filosofia Test Driven Development (TDD). En resumen, la filosofia TDD consiste en que primero se crea el test y posteriormente se desarrolla el software que cumple dicho test. Esta filosofia tiene dos puntos muy fuertes:

•  Define los requisitos de forma mucho mas exacta que un documento de texto.
•  Una vez implementados el test y el software que cumple dicho test la automatización de las pruebas del software esta hecha también.

Parece ideal¿no? entonces ¿por que no se usa en todos los desarrollos? El gran problema es que un test automático (me refiero a un test que merezca la pena hacer) necesita que este muy "maduro" el desarrollo. 

Pongamos, por ejemplo, una web de gestión de usuarios. Un test muy obvio es "alta de usuario" pero para dar de alta un usuario seguramente se necesite:

• Base de datos
• Validaciones
• Autorizaciones
• Etc..

Estos conceptos se deben definir desde el principio pero a alto nivel, si se intenta definir hasta el ultimo campo de la base de datos, hasta el ultimo método del fichero de codigo que implementa la validación, etc.. solo se conseguirá gasta mucho tiempo (y dinero) en una definicion que se va a cambiar seguro.

Entonces, debemos olvidarnos del TDD? La respuesta es no. Lo que se debe hacer es adoptar esta filosofia en una fase mas madura del desarrollo y tener en cuenta que se debe facilitar la adopción de esta filosofia en la filosofia que se use para empezar.