miércoles, 29 de octubre de 2008

Introducción a las pruebas unitarias (I)

Directamente relacionado con los últimos posts de metodologías ágiles, scrum, publicados, en este artículo voy a tratar de explicar de manera sencilla que son las pruebas unitarias y en que nos puede ayudar su adopción. En un segundo artículo veremos un pequeño ejemplo de cómo aplicarlas con ayuda de las herramientas que nos proporciona Visual Studio.

¿Qué son?

Las pruebas unitarias (o Unit Testing cómo encontrareis en la mayoría de documentación existente) no son más que un mecanismo que nos permiten realizar pruebas de manera automatizada sobre las clases y componentes de nuestro código. A pesar de que las pruebas unitarias existen desde hace muchísimo tiempo en el mundo del desarrollo de software, ha sido el auge cada vez más grande de las metodologías ágiles lo que las ha popularizado hasta los límites en que se encuentran hoy en día, al ser una de las técnicas que más adeptos tiene entre los “adoptantes” de dichas metodologías.

También es importante destacar que dentro del contexto de las pruebas unitarias se pueden diferenciar dos corrientes importantes:

· Test-Last Development: O escribir las pruebas una vez realizado el código.

· Test-First Development: Escribir las pruebas antes del código, y a base de refactorización derivar éste último. Ésta corriente es la base del Test Driven Development (o desarrollo guiado por tests).

Cada una tiene sus ventajas e inconvenientes, pero si un equipo está en proceso de adopción de las pruebas unitarias yo, a modo personal, recomendaría una primera aproximación a desde el punto de vista del Test-Last Development.

¿Qué aportan?

Después de esta breve introducción vamos a ver en que nos puede ayudar realizar pruebas automáticas de nuestros desarrollos:

  • Facilidad en la integración de cambios. Gracias a los tests unitarios es inmediato ver si un cambio realizado por nosotros hace que deje de funcionar otra parte del código.
  • Documentación “dinámica” del código (Crece y se actualiza a la misma velocidad que lo hace el código)
  • Facilidad de refactorización. Podemos mejorar, optimizar y simplificar partes de nuestro código con la tranquilidad de saber que si el test que cubría aquella parte sigue siendo válido, el código también lo es.
  • Obligatoriedad de un análisis explícito previo al desarrollo. Para poder realizar las pruebas el desarrollador necesita entender realmente el alcance de la funcionalidad que va a implementar
  • Mejor diseño del software debido al punto anterior
    • Menos acoplamiento
    • Más mantenibilidad
    • Más legibilidad
  • Código más reutilizable. Al tener un mejor diseño de los componentes estos se pueden reutilizar con mayor facilidad haciendo que incremente la productividad del equipo.
  • Detección temprana de bugs. Por lo general cuanto más tarda en detectarse un fallo más impacto tiene en el cliente y mas impacto tiene en la dinámica de trabajo del equipo. Por lo tanto la detección de errores en las primeras fases de desarrollo asegura un menor impacto en el producto y de nuevo una mayor productividad.
  • Reducción del tiempo de depuración.

Todas estas ventajas que nos proporcionan los tests unitarios se pueden resumir en dos grandes mejoras, que, aunque parezcan contrarias, van realmente muy ligadas la una a la otra:

· Mayor velocidad de desarrollo

· Mayor calidad en el producto final

El principal problema para la adopción de las pruebas unitarias en un equipo surge si estas son vistas cómo un coste, y no cómo una inversión.

¿Cómo vamos a aumentar la velocidad de desarrollo si tenemos que perder tiempo en codificar las pruebas unitarias?

Aunque parezca una paradoja la realidad es que la inversión de tiempo realizada en el desarrollo de pruebas unitarias tiene un retorno muy rápido y en muy poco espacio de tiempo veremos cómo la calidad del código desarrollado

En este caso lo que hay que entender es que las pruebas unitarias son una inversión y no un coste, pero además son una inversión con un retorno de la misma casi inmediato y con unas ganancias para el equipo de desarrollo (y para todos los que dependan en mayor o menor medida de el trabajo de éstos) realmente abundantes.

Aparte de todo esto, no se debe perder de vista una máxima crucial en el mundo del desarrollo: la calidad del código nunca es negociable, lo que implica que las pruebas (ya sean unitarias o manuales) nunca deben ser opcionales, y por lo tanto la adopción de pruebas unitarias no debería ponerse en duda si de lo que se trata es de asegurar la calidad de nuestro código.

Y esto es todo, en el próximo post veremos una visión práctica de lo expuesto en este artículo utilizando el Framework de Test integrado en Visual Studio, MSTest.

No hay comentarios: