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.
Comentarios
Publicar un comentario