En la reunión 30 de la comunidad TjNet estaré presentando el tema TDD (Test Driven Development), el cual es una práctica de programación que consiste en escribir primero las pruebas unitarias, después el código que cumple con las pruebas y refactorizar el código escrito.
La idea principal es que el comportamiento esperado del objeto que estamos probando lo definamos en pruebas y después nos preocupemos por que el objeto cumpla con lo que se definió en las pruebas.
Cabe aclarar que el TDD es una actividad del equipo de desarrollo y no del equipo de QA que realiza las pruebas al software. La intención de las pruebas unitarias no es que el equipo de calidad las use para realizar su trabajo. Las pruebas unitarias son para definir el comportamiento del código que vamos escribir, es decir es parte del diseño. Aunque sí aumentan en cierta forma la calidad del código escrito.
Efectos del desarrollo guiado por pruebas
Algunos de los efectos notables sobre el desarrollo guiado por pruebas es que se evita escribir código que no se utilizará. Ya que se trata de realizar solamente el código necesario para poder satisfacer las pruebas definidas.
Otro efecto que se obtiene al trabajar de esta manera es que como nuestras clases ya no solo van a ser utilizadas por la aplicación, sino también por el código de prueba, esto nos obliga a tener clases débilmente acopladas y que hacen uso de dependencias solo a través de interfaces, independientemente de la implementación. De tal forma que sea fácil utilizar ciertas clases concretas para la aplicación y otras para las pruebas. Para esto es común aplicar el principio de inyección de dependencias.
El mantenimiento del código es más manejable, la confianza en el código mejora, por que las pruebas nos sirven como alerta cuando introducimos código que hace que nuestras pruebas fallen. En lugar de introducir cambios al código sin saber cómo afectan a otras clases del sistema.
El uso del depurador disminuye ya que cuando existe un error en el código es más fácil encontrarlo en las pruebas que corriendo la aplicación en modo debug.
Ciclo de desarrollo
1. Escribir el comportamiento deseado (requerimiento) a manera de prueba unitaria, Este paso fuerza al programador a tomar la perspectiva de un cliente considerando el código a través de sus interfaces. Obviamente la prueba fallará ya que aun no está escrito el código para satisfacerla.
2. Escribir solo el código necesario para que la prueba pase.
3. Correr las pruebas para confirmar que efectivamente el código escrito cumple con los establecido por las pruebas.
4. Refactorizar el código, para eliminar código duplicado y dejarlo de tal forma que sea fácil hacerle modificaciones en el futuro.
5. Verifica que las pruebas no fallen después de la refactorización.
Conclusión
El desarrollo guiado por pruebas no es parte del proceso de calidad de un sistema en desarrollo (aunque si aumenta la calidad del código escrito) sino que forma parte del diseño de cada clase; define el comportamiento esperado de la clase desde el punto de vista del cliente que la usará.
Los espero en la reunión 30 de la comunidad TjNet.
Comentarios
Publicar un comentario