Hace un par de días tuve la oportunidad de asistir al curso sobre Test Driven Development (Desarrollo orientado a Test o TDD, por sus siglas en inglés) que impartieron Luis Rovirosa y Jordi Anguela a través de codium.team.
Antes del curso desarrollé un pequeño proyecto personal con Ruby on Rails y realizando test Unitarios, así como test a los controladores e incluso algunos test de integración que abarcaban procesos como: el de registro, el de recuperación de la cuenta y el de inicio de sesión .
El curso me ha parecido muy revelador porque, a pesar de tener algunas nociones básicas, haber basado el proyecto anterior en el libro Agile Web Development with Rails 4 y haberme iniciado un poco en el mundo de los test, bastaron unos simples ejercicios para ser consciente de la magnitud del trabajo que implica realizar un buen TDD y no meros test.
Dicho de otro modo: «Los árboles no te dejan ver el bosque.»
En mi caso, me centré en realizar algunos test de varios tipos pero, debido a la falta práctica, los basaba en el diseño y no al revés. De este modo, cambia enfoque lo que dificulta la comprensión del proceso.
El curso tiene una duración de 2 días y está dividido en una parte teórica y una parte práctica organizada en torno a una kata. Durante la parte práctica, ambos instructores tratan de hacerte reflexionar acerca de los problemas planteados.
Las katas se hacen en parejas en la máquina de uno de los dos componentes y realizando rotación de compañeros en cada ejercicio. Este método resulta especialmente enriquecedor, ya que todos los alumnos comparten su enfoque a la hora de solucionar cada problema, utilizando diversos lenguajes de programación que no siempre son conocidos por todos los alumnos, lo que permite abstraerse del lenguaje y centrarse en problema que plantea la kata.
El principal descubrimiento durante las katas es lo lejos que se está a veces de la solución más sencilla para un determinado requisito. En mi opinión, esto ocurre debido a la tendencia generalizada a anticipar el proceso, complicando así más de lo necesario el diseño.
Me resultó especialmente divertida la kata password-validator en la que, a medida que desarrollábamos los distintos test, Luis aparecía de pronto para realizar un transgresor refactor borrando parte de nuestro código (la mayoría de las reglas) y todos los test seguían en verde. No pude evitar sonreír ante la habilidad del profesor.
Por consiguiente todos los test deben tener un determinado objetivo. Los objetivos de los que nos ocupábamos mi compañero y yo no eran de utilidad, es decir, nos encontrábamos desarrollando unos test inútiles en la práctica.
También tuvimos la oportunidad de hacer prácticas en materia de creación de test de seguridad sobre un código legado para más tarde hacer un refactor con cierta seguridad sin modificar el comportamiento observable. Sin duda fue uno de los ejercicios más didácticos del curso.
En otro orden de cosas, ampliaron nuestra perspectiva en materia de realización de test sobre librerías de terceros con herramientas como stub, mock, spy, etc, tanto de manera manual como con librerías especializadas como Prophecy.
En la última kata utilizamos un enfoque diferente donde el diseño Outside-in (Escuela de Londres) en el que se empieza por la funcionalidad final y se implementa poco a poco todo lo necesario.
En conclusión, el curso da pequeñas pinceladas de un amplio proceso de desarrollo de software, que puede servir de base para los más osados que decidan meterse más en harina y especializarse en este ámbito.
No hay comentarios:
Publicar un comentario