0:00:05.200,0:00:10.640
Hola a todos, mi nombre es Mauricio y estoy aquí para defender la cobertura de código hoy.

0:00:11.680,0:00:17.600
¿Por qué? Bueno, porque estoy bastante seguro de que todos hemos escuchado cosas como: "La cobertura de código es inútil

0:00:17.600,0:00:22.960
porque puede ser engañada, o porque me obliga a escribir pruebas inútiles, o porque, ya sabes,

0:00:22.960,0:00:26.080
si escribes pruebas sin aserciones tu cobertura será alta pero tus 

0:00:26.080,0:00:31.600
pruebas no estarán probando nada,o 100 de cobertura de código, no significa que tus pruebas sean buenas, 

0:00:32.160,0:00:37.920
bla, bla, bla". Pero déjame decirte algo: si realmente crees en eso, es simplemente porque 

0:00:37.920,0:00:47.600
no lo estás usando adecuadamente, ya sabes, hacer tiempo de caída, y eso es todo. No te preocupes, hay una manera de

0:00:47.600,0:00:54.960
utilizar la cobertura de código y vamos a hablar de ello ahora.
En primer lugar, la cobertura de código debe utilizarse para

0:00:54.960,0:01:01.040
aumentar - para mejorar sus conjuntos de pruebas, y no como algo que sólo tiene que tener, ¿verdad? ¿Qué

0:01:01.040,0:01:07.360
quiero decir con aumentar los conjuntos de pruebas? Piensa en cómo los desarrolladores escriben software. Así por ejemplo,

0:01:07.360,0:01:12.640
tienes que implementar una funcionalidad. Entonces empiezas un bucle de implementación de un poco de código de producción

0:01:12.640,0:01:17.440
y luego un poco de código de prueba - no importa si haces desarrollo dirigido por pruebas o

0:01:17.440,0:01:24.720
no - en algún momento simplemente has terminado, y entonces surge una gran pregunta, y la pregunta es: 

0:01:24.720,0:01:30.400
"¿Esta prueba es suficiente? ¿He probado todo lo que tenía que probar?" Y aquí es precisamente donde 

0:01:30.400,0:01:35.760
entra en juego la cobertura de código, porque se puede obtener la información a partir de ella. ¿Y cómo 

0:01:35.760,0:01:41.520
lo haces? Bueno, ejecutas tu herramienta de cobertura de código, ves lo que cubriste, lo que no cubriste,

0:01:41.520,0:01:48.240
reflexionas sobre ello, puede que escribas más pruebas, repites el ciclo hasta que sientas que has terminado,

0:01:48.240,0:01:53.840
y cuando hayas terminado habrás terminado, ¿no?
Permítanme hablar un poco más sobre esto,

0:01:55.040,0:01:59.600
cómo sabemos que hemos terminado, ¿verdad? Normalmente las preguntas que me hago es,

0:02:00.640,0:02:05.440
cuando miro la línea que no está cubierta, por ejemplo, me pregunto, ¿por qué no está cubierta?

0:02:05.440,0:02:12.640
Porque cuando estaba escribiendo las pruebas con la especificación en mente, ¿por qué se me pasó esta línea?,

0:02:12.640,0:02:16.720
right? Maybe there's a reason for that. Maybe I just forgot about it, then I just write the test.¿no? Tal vez haya una razón para ello. Tal vez me olvidé de ella, y luego simplemente escribí el test.

0:02:17.680,0:02:22.400
Pero tal vez es sólo porque es algo que realmente no merece ser probado,

0:02:22.400,0:02:26.240
tal vez es sólo un método de obtención que no me parece que sea necesario probar porque, ya sabes, escribir

0:02:26.240,0:02:31.360
una prueba para esta línea no será realmente una prueba fuerte - nunca revelará un error o algo, ¿verdad?,

0:02:32.560,0:02:39.760
así es como respondo a, "¿Es esto suficiente?" Y el último punto de ahí, ya sabes,

0:02:39.760,0:02:43.120
esto es algo que siempre debes evitar, no debes escribir una prueba sólo porque, ya sabes,

0:02:43.120,0:02:47.200
quieres aumentar tu número de cobertura, esa no es una buena razón para escribir una prueba.

0:02:48.880,0:02:54.320
Genial, así que ya sabes que la cobertura de código se utiliza para aumentar tus pruebas, y lo que acabamos de ver es

0:02:54.320,0:02:59.520
que también la cobertura de código debería ayudarte a tomar la decisión de escribir pruebas -más pruebas- o no,

0:02:59.520,0:03:04.480
pero no debería ser la que tomara la decisión por ti, ¿verdad?, tu tienes el control. La cobertura de código

0:03:04.480,0:03:12.640
sólo te da información. Entonces la pregunta del millón: ¿una mayor cobertura 

0:03:12.640,0:03:18.640
realmente conduce a un mejor software? Así que nunca he investigado la cobertura de código por mí mismo, pero un montón

0:03:18.640,0:03:24.880
de gente inteligente lo ha hecho, y voy a recorrer algunos de los documentos que me gustan.

0:03:24.880,0:03:31.840
Por ejemplo, el primero de Hutchins y sus colegas de 1994, de hace mucho tiempo, 

0:03:32.800,0:03:38.160
compararon diferentes suites de pruebas con diferentes coberturas, y vieron la efectividad de estas

0:03:38.160,0:03:43.920
suites de pruebas. Y los resultados son que las suites de pruebas que logran más del 90 por ciento de cobertura

0:03:43.920,0:03:50.720
son mejores para detectar los fallos que las suites que no logran tanta cobertura. Y eso

0:03:50.720,0:03:55.520
tiene sentido, cierto, cuanta más cobertura -más cubres- más fallos puedes encontrar,

0:03:56.160,0:04:00.720
por lo tanto es simplemente mejor.
Y otro hallazgo interesante que también coincide

0:04:00.720,0:04:09.200
con nuestra percepción es que la cobertura 100 por sí sola no es fiable, no es suficiente para indicar si 

0:04:09.200,0:04:13.840
tu conjunto de pruebas es lo suficientemente bueno. Esto significa que si tienes 100 de cobertura no significa

0:04:14.800,0:04:19.680
que tus pruebas sean perfectas o algo así.
A continuación, otro trabajo de investigación de

0:04:19.680,0:04:27.840
2009 -y- hallazgos interesantes también. Uno de ellos es que, si sigues solo añadiendo pruebas,

0:04:27.840,0:04:32.400
no es una estrategia eficiente. Lo que tienes que hacer es escribir pruebas para

0:04:32.400,0:04:38.080
cosas que aún no has probado. Así que miras la cobertura y luego escribes una prueba para eso,

0:04:38.080,0:04:43.440
y estas pruebas tendrán más probabilidades de encontrar nuevos fallos que si sólo sigues añadiendo pruebas para 

0:04:43.440,0:04:47.440
las cosas que ya has probado. Eso tiene mucho sentido, cierto, y en realidad coincide

0:04:47.440,0:04:52.640
con el procedimiento que te acabo de dar antes: así que escribes pruebas basadas en la especificación cuando estás

0:04:52.640,0:04:57.680
implementando tu característica. Una vez que has terminado, aumentas tus conjuntos de pruebas utilizando la cobertura.

0:05:00.400,0:05:06.400
Otra investigación más, en este artículo -en este trabajo- los autores descubrieron que

0:05:06.400,0:05:11.040
la cobertura no siempre está relacionada con la eficacia, así que quizás una cobertura alta no significa realmente que

0:05:11.040,0:05:17.200
tus pruebas sean buenas, pero los autores concluyen que la cobertura es muy buena para identificar

0:05:17.200,0:05:21.920
las partes del sistema que no han sido probadas correctamente, pero es muy mala si la utilizas como objetivo de calidad. Así

0:05:23.280,0:05:27.760
que lo que obtengo de esto es que nunca debes definir un objetivo de cobertura, ya sabes,

0:05:27.760,0:05:33.680
si tu empresa tiene ese número mágico que siempre debe ir por, digamos, 90 de cobertura o lo que sea,

0:05:33.680,0:05:41.600
esto tal vez no es una muy buena idea.
Por último, tenemos todo tipo de criterios de cobertura diferentes:

0:05:41.600,0:05:46.640
cobertura de líneas, cobertura de ramas, cobertura de ramas de condiciones,

0:05:46.640,0:05:52.320
cobertura de rutas, etc etc etc, pero quizá no necesites todos esos criterios extravagantes.

0:05:52.880,0:05:58.080
La cobertura de sentencias parece ser un buen indicador de la calidad de las pruebas,

0:05:58.080,0:06:02.480
¿verdad? La más simple - la cobertura de sentencias - cualquier herramienta puede calcularla, no importa 

0:06:02.480,0:06:06.640
realmente el lenguaje de programación, así que no tienes que ir a por cosas súper sofisticadas:

0:06:09.680,0:06:17.120
las cosas básicas siempre funcionan, ¿cierto?, y eso me encanta.
Un último consejo, algo que también obtuvimos

0:06:17.120,0:06:21.600
de estos documentos, es que una alta cobertura puede no significar mucho, ¿correcto?, el 100 por ciento de cobertura no 

0:06:21.600,0:06:27.360
que tus pruebas sean perfectas, pero una baja cobertura significa mucho, correcto, significa que tu suite de pruebas

0:06:27.360,0:06:35.360
es débil - puede no revelar todos los errores que quieres revelar. Autopromoción descarada,

0:06:35.360,0:06:41.120
acabo de escribir un libro sobre pruebas de software, hay un capítulo entero sobre esto. Déjenme resumir mi

0:06:41.120,0:06:47.680
charla, así que, no odien la cobertura de código porque la cobertura de código no odia. Solo hay que usarla

0:06:47.680,0:06:54.960
correctamente. ¿Cómo lo hacemos? Usamos la cobertura para aumentar nuestro conjunto de pruebas, usamos la cobertura para informar

0:06:54.960,0:06:59.280
la decisión de si debo probar un poco más o no, pero no toma la decisión por ti,

0:07:00.240,0:07:13.120
y finalmente, la cobertura alta puede no significar nada, pero la cobertura baja significa mucho. Muchas gracias.