Mi nombre es Davide, hola desde el sur de Suecia, y me gustaría empezar a contar un poco mi historia personal con - con el desarrollo dirigido por pruebas. Esto comenzó cuando yo era un estudiante de posgrado, y como cualquier estudiante de posgrado, tenía algunos proyectos secundarios en los que estaba trabajando, principalmente utilizando Ruby on Rails. Y si estás familiarizado con el marco de trabajo y la comunidad detrás de ese marco de trabajo, este es el tipo de comunidad que jura - y es devota a las pruebas unitarias - y específicamente al desarrollo dirigido por pruebas. También, al mismo tiempo, estaba decidiendo sobre el tema de mi disertación, y me pareció interesante estudiar algo que a la comunidad de profesionales se le ocurrió - con algo que inventaron, y luego adoptó, en lugar de venir con algo académico y que tal vez - nadie va a terminar usando en la práctica. Y, comencemos con uno de los costos ocultos, tal vez, la falsa publicidad de lo que es el desarrollo dirigido por pruebas. Así es como normalmente se te presenta TDD: es un proceso simple, iterativo, de tres pasos. Tenemos una fase roja y otra verde que se asemejan a los colores de los marcos de pruebas que se suelen utilizar para indicar si se falla o se pasa el conjunto de pruebas. Empezamos escribiendo un caso de prueba que falla, así que estamos en la llamada fase roja, y luego pasamos a la fase verde escribiendo suficiente código para hacer que la prueba pase. Luego tenemos una fase azul adicional en la que podemos refactorizar, y el ciclo continúa añadiendo nuevos casos de prueba que fallan y así sucesivamente.
En realidad creo que eso es una simplificación excesiva, y en realidad una idea errónea de lo que es TDD. De hecho se parece un poco más a esto: Hay dos fases distintas con diferente función: Una impulsada por los casos de pruebas unitarias como contratos que necesitas cumplir donde muchas cosas pueden ir mal. Tienes que retroceder, tienes que hacer cambios en los casos de prueba, tienes que luchar contra tu deseo de escribir más código de prueba del que realmente es necesario sólo porque sabes que vas a escribirlo eventualmente de todos modos. Y luego hay una segunda parte en la que intentas alinear la necesidad de tu código, o la necesidad que puede tener tu código, con el diseño y normalmente lo llamamos refactorización. Y esto trae su propio conjunto de complicaciones. Así que, por ejemplo, dependiendo de la refactorización, puede que tengas que alinear tus antiguos casos de prueba con el nuevo diseño del código, puede que tengas que arreglar algunos errores de regresión que hayas causado durante la refactorización... Otra decisión importante es que el desarrollador decida cuándo está satisfecho con la calidad del código para poder pasar al siguiente ciclo TDD.
Y aquí mi primer costo oculto es que TDD puede no ser tan simple como parecía. Y al mirar la complejidad real de TDD, me sentí como, ¿por qué alguien haría eso? Y resulta que no era el único, hay otros investigadores que han estudiado lo empinada que es la curva de aprendizaje de TDD, lo mucho que se percibe como una sobrecarga, cómo lleva al desarrollador a centrarse en las pruebas satisfactorias en lugar de probar caminos difíciles, y todas estas afirmaciones chocan con los beneficios, o los supuestos beneficios de TDD, por lo que el hecho de que el desarrollo dirigido por pruebas mejora el diseño, conduce a la reducción de los defectos, mejora la productividad de los desarrolladores, ya que los desarrolladores ahora pueden confiar en esta amplia red de seguridad hecha de pruebas unitarias.
Así que para nosotros, esto nos llevó a preguntarnos: "¿Los desarrolladores que dicen hacer TDD realmente lo hacen?". Entonces realizamos un estudio con desarrolladores profesionales que fueron formados en TDD y les pedimos que añadieran nuevas características a un sistema heredado. Ahora bien, este sistema es un sistema del mundo real, no el tipo de ejercicio de kata que la gente suele emplear para practicar el desarrollo dirigido por pruebas, y tiene una arquitectura completa, dependencia de APIs externas, un complicado análisis de XML, etc. Además, instrumentamos los IDEs de los desarrolladores con un plug-in que recoge las actividades que ocurren en el propio IDE, y que eventualmente podríamos mapear en las actividades TDD y en las fases TDD. Y empezamos a ver los resultados y esto es lo que obtuvimos. Aquí estoy mostrando sólo un ejemplo de cómo se supone que son las diferentes actividades en forma de TDD. Cada actividad tiene un tipo y una duración, así que por ejemplo aquí se puede ver que esta persona comenzó con la implementación de pruebas en primer lugar, que se muestra en amarillo, luego pasó a agregar casos de prueba sin la contraparte de código de producción en naranja, y luego hubo un lapso, y esta persona cambió durante aproximadamente media hora a un tipo de enfoque de prueba-última que se muestra en rojo. Y luego añadió más ciclos - continuó desarrollando usando primero las pruebas y haciendo refactorizaciones que se muestran en azul claro sólo al final.
Así que pusimos todas estas medidas juntas, las horas de desarrollo de más de 60 desarrolladores profesionales, y pasamos estos datos a través de un modelo estadístico y ¿qué aprendimos? Bueno, observamos que el principal beneficio de hacer el desarrollo dirigido por pruebas es, por lo que las únicas cosas, o de las cosas que cuenta, que explica los beneficios percibidos o los beneficios declarados de TDD, como la calidad del código, así como la productividad, bueno, esa cosa no es la rígida, la adhesión religiosa al ciclo del desarrollo impulsado por pruebas, sino más bien la granularidad que tienen las actividades en el proceso. Así que el hecho de que cada actividad, como la escritura de código y la escritura de pruebas, o al revés, incluso, la escritura de código de pruebas y luego la refactorización, se mantienen dentro de un intervalo de tiempo corto y consistente. Así que esa es la salsa secreta de TDD. Hay que tener en cuenta que esta granularidad es un subproducto del desarrollo guiado por pruebas: no está impuesta por él. Se recomienda mantener un ciclo corto -de cinco a diez minutos- aunque observamos que muy poca gente lo hace, especialmente en el caso del código heredado. Y lo que es más importante, este ritmo de TDD se ve directamente afectado por el alcance de los casos de prueba definidos para iniciar cada ciclo. Así que una sugerencia aquí es ser realmente consciente del alcance del caso de prueba - lo que realmente ayuda es trabajar en pasos pequeños. Así que, ahora tenemos, ahora sabemos que se puede beneficiar de TDD, aunque no directamente debido a este enfoque de la prueba primero, sino más bien porque hace más convincente escribir pequeñas pruebas unitarias.
Por último, otro aspecto que hemos comenzado y que realmente me pareció bastante interesante fue entender cómo los desarrolladores realmente están recibiendo el TDD como un proceso. Aquí, por un lado, tenemos el conocimiento existente, la literatura existente en la ingeniería de software que nos dice que los desarrolladores que se sienten a gusto son mejores en la resolución de problemas. Y por otro lado tenemos esto: una forma diferente de desarrollar software donde las pruebas unitarias controlan y guían las decisiones de los desarrolladores. Así que realizamos un pequeño experimento esta vez con estudiantes, novatos y desarrolladores TDD, comparándolos con desarrolladores no TDD, y les pedimos que realizaran una serie de tareas de desarrollo, pero también les pedimos que informaran de su estado emocional percibido utilizando este maniquí pictórico aquí llamado Sam. Básicamente, podían marcar en el maniquí lo que correspondía a sus estados, como felicidad, excitación, frustración, aburrimiento, etc. Y aquí observamos otro coste oculto del desarrollo dirigido por pruebas: observamos que quienes desarrollan usando TDDs no son tan felices como otros desarrolladores. Y cuando investigamos esto, descubrimos que la razón es que TDD obliga a los programadores a entrar en este ciclo de adormecimiento mental que en realidad corta sus alas creativas, y especialmente en el caso de los novatos, simplemente se sienten incómodos con el tipo de pensamiento contraintuitivo de TDD de probar el código de producción correcto. Así que esta es mi tercera conclusión, así que sí, aunque TDD no es tan simple como podría parecer, funciona si lo usas con ciclos pequeños, pero, sin embargo, viene con un costo emocional del cual debes ser consciente.
Y esto es todo lo que tengo para ti hoy. Gracias, por supuesto puedes acercarte y preguntarme más y conectarte conmigo, este es mi correo electrónico y mi Twitter. Gracias por tu tiempo.