Uno de los factores clave a la hora de realizar un código seguro y de calidad, es utilizar TDD. 



Lo primero que tenemos que tener en cuenta es que TDD no es la panacea, me explico: no por hacer esta práctica, vamos a dejar de tener errores y vamos a ser los mejores desarrollando. El utilizar esta práctica, mejora la calidad del código y, sobre todo, nos 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 de suceder para que todo funcione correctamente, pero el trabajo de un tester es pensar que va a salir mal y encontrar una manera de garantizar que no pase. Esta es una de las principales ideas del porque, el TDD nos ayudará, pero siempre 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 utilizamos TDD, la prueba se realiza antes de escribir el código que queremos, por lo tanto, no hay nada que probar y no la podemos catalogar como “prueba”, si no que es una casuística de algo que queremos que haga el desarrollo futuro. Esto nos ayudará a saber que debemos de hacer, como hacerlo y como tiene que funcionar, además de asegurarnos de que esa casuística concreta funciona correctamente.

Si queremos tener una buena base para comenzar a realizar TDD, nos debemos de apoyar en los criterios de aceptación, ya que en ellos tenemos toda la información de lo que se va a realizar, por lo tanto, las pruebas unitarias deben de cubrir estos criterios de manera total. 
Para mi, este punto es el más importante de todos, ya que, cualquier proyectos que se precie, tiene que tener unos criterios de aceptación y unos requisitos perfectos, si no, ya empezaremos a tener problemas desde el principio.

Si queremos comenzar a utilizar TDD, tiene que ser de manera progresiva y estoy seguro de que al principio no irá tan rodado como pensamos, es algo más complejo de lo que parece. La idea es practicar muchísimo y obtener la máxima habilidad para realizarlo. Creo que una buena estrategia es comenzar a realizar TDD en una pequeña funcionalidad e involucrar a todas las personas del proyecto, comentando que se añada cierta margen de tiempo para que el resultado sea adecuado. 

Otra buena práctica, es ponerlo en práctica en un proyecto interno, para que las personas que lo hagan, comiencen a coger experiencia y velocidad de cara a implantarlo en proyectos externos.

El TDD nos da robustez de código, de eso no tengo 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 muchísimo y dejando tiempo y espacio a las personas para que puedan avanzar día tras día.

Un buen comienzo para aprender a realizar TDD de manera ágil, 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