Uno de los factores clave a la hora de realizar un código seguro y de calidad es utilizar TDD.
Lo primero que debemos tener en cuenta es que TDD no es la panacea y vamos a contar el por qué: no por ponerlo en práctica vamos a dejar de tener errores y vamos a ser los mejores desarrollando. Utilizar esta práctica, mejora la calidad del código y, sobre todo, proporciona una manera ágil de hacer testing a la vez que desarrollamos, pero tiene bastantes contradicciones si no se aplica o se utiliza correctamente.
Cuando un desarrollador utiliza TDD, lo hace de manera optimista y se centra en ver lo que debe suceder para que todo funcione correctamente. Sin embargo, el trabajo de un tester es pensar que va a salir mal y encontrar una manera de que no pase. Esta es una de las ideas del por qué TDD nos ayudará, pero debemos de contar con personas de QA que validen lo que hacemos.
Otra idea que no es del todo correcta es la de test unitario. Cuando se utiliza TDD, la prueba se realiza antes de escribir el código que queremos, por lo tanto, no hay nada que probar y no se puede catalogar como “prueba”, sino que es una casuística de algo que se pretende que haga el desarrollo futuro. Esto ayudará a saber qué se debe de hacer, cómo hacerlo y cómo tiene que funcionar, además de asegurar que esa casuística funciona correctamente.
Si se quiere tener una buena base para comenzar a realizar TDD, se debe de contrastar todo con los criterios de aceptación. Esto se debe a que en ellos se tiene la información de lo que se va a realizar, por lo tanto, las pruebas unitarias deben de cubrir estos criterios de manera total.
De forma objetiva, este punto es el más importante de todos. Cualquier proyecto debe tener unos criterios de aceptación y unos requisitos perfectos, si no, ya se va a empezar a tener problemas desde el principio.
Para comenzar, realiza TDD en una pequeña funcionalidad e involucra a las personas del proyecto
Si se pretende comenzar a utilizar TDD tiene que ser de manera progresiva. Seguro que al principio no irá tan rodado como se piensa, ya que es algo más complejo de lo que parece. La idea es practicar muchísimo y obtener la máxima habilidad para realizarlo. Por ello, una buena estrategia sería la de comenzar a realizar TDD en una pequeña funcionalidad e involucrar a todas las personas del proyecto, contrastando siempre que se añada cierto margen de tiempo para que el resultado sea adecuado (alrededor del 10% del tiempo de sprint).
Otra buena práctica, es realizarlo inicialmente en un proyecto interno, para que las personas cojan experiencia y velocidad de cara a implantarlo en proyectos externos.
El TDD da robustez de código, de eso no hay ninguna duda, y es muy gratificante que las validaciones se realicen de manera inmediata, detectando problemas al momento y pudiendo solucionar todo antes de que se ponga en el entorno de pruebas.
La única manera de que un equipo comience a realizar TDD es practicando y dejando tiempo y espacio para que puedan avanzar día tras día.
Un buen comienzo para aprender a realizar TDD ágilmente, es leer el libro de Carlos Blé que se puede descargar de manera gratuita en PDF.
También hay otro libro en castellano muy apropiado para comenzar con el TDD.
Y uno de los clásicos (ya que data del 2002) es este de Kent Beck
0 comentarios