0:00:05.520,0:00:12.320
Mi nombre es Davide, hola desde el sur de Suecia, 
y me gustaría empezar a contar un poco mi

0:00:12.320,0:00:17.200
historia personal con - con el desarrollo dirigido 
por pruebas. Esto comenzó cuando yo era

0:00:17.200,0:00:22.240
un estudiante de posgrado, y como cualquier estudiante de posgrado, 
tenía algunos proyectos secundarios en los que estaba trabajando,

0:00:22.240,0:00:26.480
principalmente utilizando Ruby on Rails. Y si estás familiarizado 
con el marco de trabajo y la comunidad

0:00:26.480,0:00:31.200
detrás de ese marco de trabajo, este es el tipo 
de comunidad que jura - y es devota a

0:00:31.760,0:00:36.320
las pruebas unitarias - y específicamente al desarrollo dirigido por pruebas. 
También, al mismo tiempo, estaba decidiendo

0:00:36.320,0:00:42.000
sobre el tema de mi disertación, y me 
pareció interesante estudiar algo que

0:00:42.000,0:00:47.200
a la comunidad de profesionales se le ocurrió - con algo que 
inventaron, y luego adoptó, en lugar de

0:00:47.200,0:00:52.960
venir con algo académico y que tal vez - 
nadie va a terminar usando en la práctica.

0:00:53.920,0:00:59.680
Y, comencemos con uno de los costos ocultos, 
tal vez, la falsa publicidad de lo que

0:00:59.680,0:01:05.280
es el desarrollo dirigido por pruebas. Así es como 
normalmente se te presenta TDD: es un proceso simple, iterativo,

0:01:05.280,0:01:09.600
de tres pasos. Tenemos una fase roja y otra verde 
que se asemejan a los colores de

0:01:10.320,0:01:16.400
los marcos de pruebas que se suelen utilizar para indicar 
si se falla o se pasa el conjunto de pruebas. Empezamos

0:01:16.400,0:01:21.680
escribiendo un caso de prueba que falla, así que 
estamos en la llamada fase roja, y luego pasamos a 

0:01:21.680,0:01:27.360
la fase verde escribiendo suficiente código para hacer 
que la prueba pase. Luego tenemos una fase azul adicional

0:01:27.360,0:01:33.280
en la que podemos refactorizar, y el ciclo continúa añadiendo 
nuevos casos de prueba que fallan y así sucesivamente.

0:01:34.160,0:01:38.800
En realidad creo que eso es una simplificación excesiva, 
y en realidad una 

0:01:38.800,0:01:45.920
idea errónea de lo que es TDD. De hecho se parece un 
poco más a esto: Hay dos fases distintas 

0:01:45.920,0:01:51.280
con diferente función: Una impulsada por los casos de 
pruebas unitarias como contratos que necesitas cumplir

0:01:51.280,0:01:55.840
donde muchas cosas pueden ir mal. Tienes que retroceder, tienes que 
hacer cambios en los casos de prueba,

0:01:55.840,0:02:00.560
tienes que luchar contra tu deseo de escribir más 
código de prueba del que realmente es necesario

0:02:00.560,0:02:05.120
sólo porque sabes que vas a escribirlo eventualmente
de todos modos. Y luego hay una segunda parte

0:02:05.120,0:02:10.000
en la que intentas alinear la necesidad de tu código, o la 
necesidad que puede tener tu código, con el diseño

0:02:10.000,0:02:16.160
y normalmente lo llamamos refactorización. Y esto trae 
su propio conjunto de complicaciones. Así que, por ejemplo,

0:02:16.160,0:02:20.880
dependiendo de la refactorización, puede que tengas que alinear 
tus antiguos casos de prueba con el nuevo diseño del código,

0:02:20.880,0:02:26.320
puede que tengas que arreglar algunos errores de regresión 
que hayas causado durante la refactorización... 

0:02:26.320,0:02:31.040
Otra decisión importante es que el 
desarrollador decida cuándo está

0:02:31.040,0:02:36.560
satisfecho con la calidad del código para 
poder pasar al siguiente ciclo TDD.

0:02:37.200,0:02:44.800
Y aquí mi primer costo oculto es que TDD puede 
no ser tan simple como parecía. Y al mirar la

0:02:44.800,0:02:50.160
complejidad real de TDD, me sentí como, 
¿por qué alguien haría

0:02:50.160,0:02:55.680
eso? Y resulta que no era el único, 
hay otros investigadores que han

0:02:55.680,0:03:01.600
estudiado lo empinada que es la curva de aprendizaje de TDD, 
lo mucho que se percibe como una sobrecarga,

0:03:01.600,0:03:08.560
cómo lleva al desarrollador a centrarse en las pruebas 
satisfactorias en lugar de probar caminos difíciles,

0:03:08.560,0:03:14.320
y todas estas afirmaciones chocan con los beneficios, 
o los supuestos beneficios de TDD, por lo que el hecho de que

0:03:14.320,0:03:19.280
el desarrollo dirigido por pruebas mejora el diseño, 
conduce a la reducción de los defectos, mejora la productividad

0:03:19.280,0:03:24.640
de los desarrolladores, ya que los desarrolladores ahora pueden confiar en 
esta amplia red de seguridad hecha de pruebas unitarias.

0:03:25.200,0:03:30.800
Así que para nosotros, esto nos llevó a preguntarnos: "¿Los 
desarrolladores que dicen hacer TDD realmente lo hacen?".

0:03:31.600,0:03:35.920
Entonces realizamos un estudio con desarrolladores 
profesionales que fueron formados en TDD

0:03:35.920,0:03:40.880
y les pedimos que añadieran nuevas características a un sistema heredado. 
Ahora bien, este sistema es un sistema del mundo real,

0:03:40.880,0:03:47.040
no el tipo de ejercicio de kata que la gente suele emplear 
para practicar el desarrollo dirigido por pruebas,

0:03:47.600,0:03:53.680
y tiene una arquitectura completa, dependencia de 
APIs externas, un complicado análisis de XML, etc.

0:03:53.680,0:04:00.400
Además, instrumentamos los IDEs de los desarrolladores con 
un plug-in que recoge las actividades que ocurren en

0:04:00.400,0:04:07.440
el propio IDE, y que eventualmente podríamos mapear en 
las actividades TDD y en las fases TDD. Y

0:04:07.440,0:04:12.080
empezamos a ver los resultados y esto es lo que obtuvimos. 
Aquí estoy mostrando sólo un ejemplo de cómo

0:04:12.080,0:04:18.640
se supone que son las diferentes actividades en forma 
de TDD. Cada actividad tiene un tipo y

0:04:18.640,0:04:23.280
una duración, así que por ejemplo aquí se puede ver que esta 
persona comenzó con la implementación de pruebas en primer lugar,

0:04:23.280,0:04:29.040
que se muestra en amarillo, luego pasó a agregar 
casos de prueba sin la contraparte de código de producción

0:04:29.040,0:04:35.680
en naranja, y luego hubo un lapso, y esta persona 
cambió durante aproximadamente media hora

0:04:35.680,0:04:43.520
a un tipo de enfoque de prueba-última que se muestra en rojo. 
Y luego añadió más ciclos - continuó

0:04:43.520,0:04:48.880
desarrollando usando primero las pruebas y haciendo refactorizaciones 
que se muestran en azul claro sólo al final.

0:04:49.520,0:04:54.640
Así que pusimos todas estas medidas juntas, 
las horas de desarrollo de más de 60

0:04:54.640,0:04:59.840
desarrolladores profesionales, y pasamos estos datos a 
través de un modelo estadístico y ¿qué aprendimos?

0:05:00.720,0:05:04.640
Bueno, observamos que el principal beneficio 
de hacer el desarrollo dirigido por pruebas es,

0:05:05.200,0:05:10.880
por lo que las únicas cosas, o de las cosas que cuenta, 
que explica los beneficios percibidos o los beneficios

0:05:10.880,0:05:17.440
declarados de TDD, como la calidad del código, así como la productividad, 
bueno, esa cosa no es la rígida,

0:05:17.440,0:05:23.120
la adhesión religiosa al ciclo del desarrollo impulsado 
por pruebas, sino más bien la granularidad que tienen

0:05:23.120,0:05:28.080
las actividades en el proceso. Así que el hecho de que cada 
actividad, como la escritura de código y la escritura de pruebas,

0:05:28.080,0:05:33.600
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

0:05:33.600,0:05:40.080
y consistente. Así que esa es la salsa secreta de TDD. 
Hay que tener en cuenta que esta granularidad es

0:05:40.080,0:05:45.280
un subproducto del desarrollo guiado por pruebas: 
no está impuesta por él. Se recomienda mantener un ciclo

0:05:45.280,0:05:50.400
corto -de cinco a diez minutos- aunque observamos 
que muy poca gente lo hace, especialmente

0:05:50.400,0:05:57.040
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

0:05:57.040,0:06:03.280
de los casos de prueba definidos para iniciar cada ciclo. 
Así que una sugerencia aquí es ser realmente consciente

0:06:03.280,0:06:07.680
del alcance del caso de prueba - lo que realmente 
ayuda es trabajar en pasos pequeños. Así que,

0:06:08.640,0:06:13.600
ahora tenemos, ahora sabemos que se puede beneficiar 
de TDD, aunque no directamente debido

0:06:13.600,0:06:19.840
a este enfoque de la prueba primero, sino más bien porque 
hace más convincente escribir pequeñas pruebas unitarias.

0:06:21.680,0:06:28.640
Por último, otro aspecto que hemos comenzado y 
que realmente me pareció bastante interesante fue entender

0:06:28.640,0:06:34.800
cómo los desarrolladores realmente están recibiendo el TDD 
como un proceso. Aquí, por un lado, tenemos el conocimiento

0:06:34.800,0:06:40.320
existente, la literatura existente en la ingeniería de 
software que nos dice que los desarrolladores que se sienten a gusto

0:06:40.320,0:06:46.080
son mejores en la resolución de problemas. Y por otro lado 
tenemos esto: una forma diferente de

0:06:46.080,0:06:50.560
desarrollar software donde las pruebas unitarias 
controlan y guían las decisiones de los desarrolladores.

0:06:51.360,0:06:57.520
Así que realizamos un pequeño experimento esta vez con 
estudiantes, novatos y desarrolladores TDD, comparándolos

0:06:57.520,0:07:05.760
con desarrolladores no TDD, y les pedimos que 
realizaran una serie de tareas de

0:07:05.760,0:07:11.920
desarrollo, pero también les pedimos que informaran de su estado 
emocional percibido utilizando este maniquí pictórico

0:07:11.920,0:07:18.160
aquí llamado Sam. Básicamente, podían marcar en el 
maniquí lo que correspondía a sus estados, como

0:07:18.160,0:07:25.440
felicidad, excitación, frustración, aburrimiento, 
etc. Y aquí observamos otro coste oculto del

0:07:25.440,0:07:30.240
desarrollo dirigido por pruebas: observamos que quienes 
desarrollan usando TDDs no son tan felices como otros desarrolladores.

0:07:30.240,0:07:36.240
Y cuando investigamos esto, descubrimos que la 
razón es que TDD obliga a los programadores a entrar

0:07:36.240,0:07:42.240
en este ciclo de adormecimiento mental que en realidad corta 
sus alas creativas, y especialmente en el

0:07:42.240,0:07:49.360
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

0:07:50.080,0:07:56.720
correcto. Así que esta es mi tercera 
conclusión, así que sí,

0:07:56.720,0:08:01.600
aunque TDD no es tan simple como podría parecer, 
funciona si lo usas con ciclos pequeños,

0:08:01.600,0:08:07.040
pero, sin embargo, viene con un costo 
emocional del cual debes ser consciente.

0:08:07.680,0:08:13.920
Y esto es todo lo que tengo para ti hoy. 
Gracias, por supuesto puedes acercarte y

0:08:13.920,0:08:24.960
preguntarme más y conectarte conmigo, este es mi correo electrónico 
y mi Twitter. Gracias por tu tiempo.