viernes, 8 de noviembre de 2013

TDD y los test de integración

La práctica de programación Test-driven Development (TDD), desarrollo guiado por pruebas, está basada en la iteración continua de 5 pasos:

  • Escribir una prueba para un requisito.
  • Verificar que la prueba falla.
  • Escribir la implementación más simple para cumplir el requisito.
  • Ejecutar las pruebas automatizadas.
  • Refactorizar código.


Con la repetición de estos pasos conseguimos que la aplicación que se escribe únicamente cumpla con los requisitos que nos han pedido, con lo cual vamos directo al grano, no escribimos más código del que toca, diseñamos la aplicación en el mismo momento que escribimos las pruebas y el código de la misma, el código resultante suele ser muy legible y entendible ya que el paso de refactorización ayuda precisamente a esto, conseguimos una gran cobertura, los test cubren un porcentaje altísimo del código, entre el 90 y el 100%, conseguimos descartar test que no aportan nada y por supuesto es un mecanismo crucial para detectar errores de regresión.

Esta claro que aporta mucho para poder realizar una buena aplicación, pero como todo tiene sus limitaciones, hay que recordar que la base en la práctica del TDD son los test unitarios, no  los test de integración y mucho menos los test de interfaz gráfica o funcionales, esto quiere decir que sea lo que se que estemos implementando debe poder probarse de forma unitaria, de aquí las limitaciones de TDD con aplicaciones que se integran con bases de datos, con objetos o sistemas distribuidos “externos”, o incluso con la propia interfaz gráfica de la aplicación. 

Está claro que con el uso de stubs o mock objects podemos hacer todo pero hay que plantearse si el esfuerzo que conlleva escribir un test para estos casos no es demasiado elevado, o bien si este test lo podemos suplir mediante un test de integración más sencillo de escribir.

Entonces si es muy costoso realizar un test unitario puede que el mejor camino sea realizar el test de integración directamente. Esto puede que rompa algo la filosofía de TDD pero creo que es más práctico, incluso pienso que si el test de integración se ejecuta en tiempos similares a los unitarios el uso en conjunto con la práctica de TDD es factible. Al fin y al cabo se trata de ser prácticos.

No hay comentarios:

Publicar un comentario