En ocasiones los desarrolladores se enfrentan a desarrollos complejos, con los tiempos ajustados donde intentan obtener un código limpio, mantenible y que funcione. TDD es una metodología que ayuda a conseguir esto y, junto a la metodología ágil, crear software de calidad en el menor tiempo posible. Nuestro SlashBoy Agustín Dotta, nos enseñará hoy en qué consiste el TDD y cómo puede ayudarnos en nuestros desarrollos.
Para entender qué es y cómo funciona el TDD debemos conocer antes su definición. TDD (Test Driven Development) a menudo se traduce como Programación orientada a test. Sin embargo, este concepto es erróneo. Una traducción más realista sería Programación dictaminada por test, donde los test son los que te indican cuánto y cómo vas escribir tu código. TDD se basa en escribir primero los test, lo que supone el mayor cambio respecto a las metodologías tradicionales, y donde estos nos indicarán qué código hay que implementar para poder hacer que funcione. Una vez tengamos el código para poder pasar el test, se refactoriza para dejar un código limpio. Esta metodología se resumen en tres etapas:- Red (pruebas): escribimos un test que debería pasar un componente de nuestra aplicación. Éste no debe compilar y debe fallar.
- Green (codificar): escribimos el código que haga pasar el test. En este caso, no hacerlo perfecto está bien visto para que lo pase ya que en la siguiente etapa se va refactorizar. Con ello lo que conseguimos es la solución más sencilla posible.
- Refactor (refactorizar): refactorizamos el código escrito en la etapa anterior para que sea código limpio y funcione.
Por tanto, con TDD sólo escribiremos código cuando un test falle, eliminando las posibles duplicidades. Una de las premisas de esta metodología es: Clear code that works. Que se resume en que aplicando TDD conseguimos un código predecible, reutilizable, que no depende del entorno y fácil de modificar.
Una de las preguntas que suele surgir a la hora de decidir si implantamos esta metodología o no es si conllevará más tiempo aplicar TDD a nuestros desarrollos. Podemos decir que a la hora de codificar sí que conlleva más tiempo. Sin embargo, éste tiempo se recuperará a la hora de buscar bugs, solucionarlos, depurar, etc. Además, no debemos olvidar que el código estará testado ante posibles errores, por lo que seremos más eficientes a la hora de hacer nuestro trabajo. También conlleva más tiempo cuando el equipo no tiene experiencia en TDD (es decir, como escribir los casos de prueba) pero a largo plazo el equipo será experto y podrá obtener todos sus beneficios.
¿Por qué se suele abandonar TDD? Las razón principal de este abandono es que se suele testar lo que no se debe o no se entiende lo que hay que testar. Otras razones serían:
- Se testa todo el código.
- Sólo se escriben test, por ejemplo, cuando se tiene una tasa de cobertura de test muy elevada.
- Se testa cosas demasiado complejas. Hay que recordar que los test son unitarios por lo que cuando un test es muy complejo se debe separar en varios test.
¿Qué necesita un test para ser un buen test?
- Debe ser rápido
- Ser reutilizable, es decir, ajo las mismas condiciones siempre se tiene que comportar igual.
- Tiene un nombre claro y explícito de tal modo que no genere dudas sobre lo que hace.
- Es atómico: es decir, sólo comprueba una cosa a la vez.
- Sólo falla si tu código está mal. No depende del entorno o de ficheros externos.
En conclusión, TDD es un proceso en el que hay que trabajar y adquirir experiencia para obtener los mejores resultados y éste es uno de los mayores problemas, pero una vez superado se ven los beneficios de ésta metodología aplicable a cualquier código. ¿Os animáis a implantarlo?
]]>
