Please enable JavaScript.
Coggle requires JavaScript to display documents.
TDD (TEST DIRVEN DEVELOPER) - Coggle Diagram
TDD (TEST DIRVEN DEVELOPER)
Es una práctica de programación que consiste en escribir primero las pruebas (generalmente unitarias), después escribir el código fuente que pase la prueba satisfactoriamente y, por último, refactorizar el código escrito.
Con esta práctica se consigue, entre otras cosas, un código más robusto, más seguro, más mantenible y una mayor rapidez en el desarrollo
TDD fue creado por Kent Beck (quien también inventó Extreme Programming y JUnit), y en esencia, es un proceso a seguir, lo cual ya lo hace diferente a un simple enfoque de pruebas primero
El proceso de diseño de software, combinando TDD con metodologías ágiles, sería el siguiente:
El proceso de diseño de software, combinando TDD con metodologías ágiles, sería el siguiente:
El cliente escribe su historia de
usuario.
Se escriben junto con el cliente los criterios de aceptación de esta historia, desglosándolos mucho para simplificarlos todo lo posible.
Se escoge el criterio de aceptación más simple y se traduce en una prueba unitaria.
Se comprueba que esta prueba falla.
Se escribe el código que hace pasar la prueba.
Se ejecutan todas las pruebas automatizadas.
Se refactoriza y se limpia el código.
Se vuelven a pasar todas las pruebas automatizadas para comprobar que todo sigue funcionando.
Volvemos al punto 3 con los criterios de aceptación que falten y repetimos el ciclo una y otra vez hasta completar nuestra aplicación.
ejemplo de resolución de la kata Mars Rover
En este sentido, las pruebas son una muy buena forma de entender el código y su funcionamiento, muchas veces incluso mejor que la documentación.
También hay que decir que no todo es perfecto en TDD, cuando llegue el momento de crear un test sobre la interfaz de la calculadora la cosa se complica. Los puntos flojos que veo en TDD son:
Hay que utilizarlo y entenderlo bien para que sea realmente productivo, te ayuda a centrarte en lo importante y a no sobrediseñar, pero es importante saber refactorizar el código según vaya evolucionando para que sea consistente.
Pruebas sobre interfaces gráficas. Aunque hay soluciones parciales propuestas, para mí TDD solo funciona en la capa de negocio, no encaja con interfaces visuales.
Bases de datos. Hacer pruebas de código que trabaja con base de datos es complejo porque requiere generar unos datos conocidos antes de hacer las pruebas y verificar que el contenido de la base de datos es el esperado después de la prueba. Los objetos simulados (MockObjects) son otra opción, pero personalmente creo que se pierde tiempo con esto.