WEBVTT

99:59:59.999 --> 99:59:59.999
y unir esas cosas

99:59:59.999 --> 99:59:59.999
antes de ese plazo

99:59:59.999 --> 99:59:59.999
haya terminado

99:59:59.999 --> 99:59:59.999
Derecho

00:00:00.579 --> 00:00:01.922
Así que nos pasamos un montón de tiempo

00:00:01.922 --> 00:00:03.322
en el último par de conferencias

00:00:03.322 --> 00:00:05.821
hablando sobre los diferentes tipos de pruebas

00:00:05.821 --> 00:00:08.219
sobre la unidad de pruebas frente a pruebas de integración

00:00:08.219 --> 00:00:10.102
acerca de cómo uso RSpec

00:00:10.102 --> 00:00:12.495
realmente aislar las partes del código que desee probar

00:00:12.495 --> 00:00:14.906
tienes además, sabes, porque de deberes 3,

00:00:14.906 --> 00:00:18.176
y otra cosas, que hemos estado haciendo BDD,

00:00:18.176 --> 00:00:20.621
donde hemos estado usando pepino para activar las historias de usuario

00:00:20.621 --> 00:00:22.953
en esencia, pruebas de integración y aceptación

00:00:22.953 --> 00:00:25.610
Has visto pruebas en un par de diferentes niveles

00:00:25.610 --> 00:00:27.634
Y la meta aquí es una especie de hacer algunas observaciones

00:00:27.634 --> 00:00:29.924
ustedes saben, vamos a respaldar un poco

00:00:29.924 --> 00:00:33.011
y ver el panorama

00:00:33.011 --> 00:00:34.956
Así que esto abarca una especie de material

00:00:34.956 --> 00:00:37.007
abarca tres o cuatro secciones del libro

00:00:37.007 --> 00:00:39.618
y quiero que acaban de golpear los puntos altos en Conferencia

00:00:39.618 --> 00:00:41.461
Por lo tanto una pregunta surge

00:00:41.461 --> 00:00:43.253
Estoy seguro de que ha llegado para todos ustedes

00:00:43.253 --> 00:00:44.526
como ha estado haciendo deberes

00:00:44.526 --> 00:00:45.695
es: "cuánto pruebas es suficiente?"

00:00:45.695 --> 00:00:48.497
Y, lamentablemente, durante mucho tiempo

00:00:48.497 --> 00:00:51.090
tipo de si esta pregunta en la industria

00:00:51.090 --> 00:00:52.180
la respuesta fue básicamente

00:00:52.180 --> 00:00:53.179
"Tenemos un plazo de envío

00:00:53.179 --> 00:00:55.000
¿cuánto podemos hacer pruebas

00:00:55.000 --> 00:00:56.667
eso es cuánto".

00:00:56.667 --> 00:00:58.153
¿Verdad? Eso es lo que tienes tiempo.

00:00:58.153 --> 00:01:00.024
Por lo tanto, ustedes saben, eso de voltear un poco

00:01:00.024 --> 00:01:01.118
Obviamente no es muy buena

00:01:01.118 --> 00:01:02.549
¿Puede hacer un poco mejor, derecho?

00:01:02.549 --> 00:01:03.702
Allí están algunas medidas estáticas

00:01:03.702 --> 00:01:06.034
como el número de líneas de código tiene su app

00:01:06.034 --> 00:01:08.216
y ¿cuántas líneas de pruebas tienes?

00:01:08.216 --> 00:01:10.290
Y no es inusual en la industria

00:01:10.290 --> 00:01:12.682
en una pieza de software comprobada

00:01:12.682 --> 00:01:14.574
el número de líneas de pruebas

00:01:14.574 --> 00:01:17.736
ir mucho más allá del número de líneas de código

00:01:17.736 --> 00:01:19.752
Así, entero múltiplos no son inusuales

00:01:19.752 --> 00:01:21.843
Y creo que incluso para una especie de, ya saben,

00:01:21.843 --> 00:01:23.229
código de investigación o trabajos

00:01:23.229 --> 00:01:26.856
una relación de ustedes saben, tal vez 1.5 no es razonable

00:01:26.856 --> 00:01:30.058
por lo tanto una veces y media la cantidad de código de prueba

00:01:30.058 --> 00:01:32.249
como el código de la aplicación

00:01:32.249 --> 00:01:34.221
Y una gran cantidad de sistemas de producción

00:01:34.221 --> 00:01:35.277
donde realmente importa sobre pruebas

00:01:35.277 --> 00:01:36.919
es mucho mayor que

00:01:36.919 --> 00:01:38.155
Quizás una mejor pregunta

00:01:38.155 --> 00:01:39.472
¿En lugar de decir: pruebas de cuánto es suficiente?

00:01:39.472 --> 00:01:42.493
¿es preguntar: Qué buena es la prueba que estoy haciendo ahora?

00:01:42.493 --> 00:01:44.351
¿Cómo profundo es?

00:01:44.351 --> 00:01:45.565
Más adelante en este semestre

00:01:45.565 --> 00:01:46.568
Profesor Sen hablará sobre

00:01:46.568 --> 00:01:48.189
un poco más acerca de los métodos formales

00:01:48.189 --> 00:01:50.857
y ordenar lo que es las fronteras de la prueba y depuración

00:01:50.857 --> 00:01:52.686
Pero un par de cosas podemos hablar

00:01:52.686 --> 00:01:54.073
basado en lo que ya sabe

00:01:54.073 --> 00:01:57.744
es algunos conceptos básicos acerca de la cobertura de la prueba

00:01:57.744 --> 00:01:59.550
Y aunque yo diría

00:01:59.550 --> 00:02:01.017
ustedes saben, que hemos estado diciendo todo el tiempo

00:02:01.017 --> 00:02:03.034
métodos formales, realmente no funcionan en grandes sistemas

00:02:03.034 --> 00:02:05.330
Creo que esa declaración, en mi opinión personal

00:02:05.330 --> 00:02:07.011
realmente es mucho menos cierto lo que solía ser

00:02:07.011 --> 00:02:09.190
Creo que hay un número de lugares específicos

00:02:09.190 --> 00:02:10.524
especialmente en pruebas y depuración

00:02:10.524 --> 00:02:12.848
donde métodos formales son realmente avanzando rápido

00:02:12.848 --> 00:02:15.756
y Koushik Sen es uno de los líderes que

00:02:15.756 --> 00:02:17.944
Por lo que tendrás la oportunidad de conocer más acerca de que más tarde

00:02:17.944 --> 00:02:21.437
pero parece por el momento, tipo de pan y mantequilla

00:02:21.437 --> 00:02:22.734
es vamos a hablar de la medición de cobertura

00:02:22.734 --> 00:02:24.475
porque es donde la goma cumple la carretera

00:02:24.475 --> 00:02:26.204
en términos de cómo serán evaluados

00:02:26.204 --> 00:02:28.631
Si estás haciendo esto de verdad

00:02:28.631 --> 00:02:29.530
¿Qué es algunos aspectos básicos?

00:02:29.530 --> 00:02:30.781
Aquí es una clase realmente simple que se puede utilizar

00:02:30.781 --> 00:02:32.902
para hablar sobre diferentes formas de medir

00:02:32.902 --> 00:02:34.801
¿cómo nuestra prueba cubre este código

00:02:34.801 --> 00:02:36.632
y existen unos niveles diferentes

00:02:36.632 --> 00:02:37.851
con terminologías diferentes

00:02:37.851 --> 00:02:40.737
No es realmente universal a través de todas las casas de software

00:02:40.737 --> 00:02:42.641
pero un común conjunto de terminología

00:02:42.641 --> 00:02:43.647
que expone el libro

00:02:43.647 --> 00:02:44.689
es que podríamos hablar de S0

00:02:44.689 --> 00:02:47.457
donde sólo podría significar que has llamado cada método una vez

00:02:47.457 --> 00:02:50.452
Así que ya sabéis, si llame foo, y se llama bar

00:02:50.452 --> 00:02:52.150
Que es la cobertura de S0: no terriblemente profundo

00:02:52.150 --> 00:02:54.688
Es un poco más estrictas S1

00:02:54.688 --> 00:02:56.137
se podría decir, que estamos llamando cada método

00:02:56.137 --> 00:02:57.288
desde cada lugar que podría llamarse

00:02:57.288 --> 00:02:58.820
Así que ¿qué significa eso?

00:02:58.820 --> 00:03:00.076
Esto significa, por ejemplo

00:03:00.076 --> 00:03:01.124
no basta con llamar a bar

00:03:01.124 --> 00:03:02.952
Tiene que asegurarse de que hay que llamarlo

00:03:02.952 --> 00:03:05.575
al menos una vez desde aquí

00:03:05.575 --> 00:03:07.161
así como llamar una vez

00:03:07.161 --> 00:03:10.370
desde cualquier función exterior podría llamar

00:03:10.370 --> 00:03:12.820
C0 que es lo que mide SimpleCov

00:03:12.820 --> 00:03:15.997
aquellos de ustedes que has metido SimpleCov funcionando

00:03:15.997 --> 00:03:18.522
Básicamente dice que ha ejecutado cada declaración

00:03:18.522 --> 00:03:20.045
ha tocado cada instrucción en el código una vez

00:03:20.045 --> 00:03:22.483
Pero la advertencia de allí es que

00:03:22.483 --> 00:03:25.587
condicionales realmente sólo cuentan como una sola instrucción

00:03:25.587 --> 00:03:28.915
Así que, si usted, no importa qué rama de este "si" tomó

00:03:28.915 --> 00:03:31.749
como tocó una de la otra rama

00:03:31.749 --> 00:03:33.350
ha ejecutado el "si" declaración

00:03:33.350 --> 00:03:35.670
Así que incluso C0 es todavía, ustedes saben, excedente de superficial

00:03:35.670 --> 00:03:37.267
Pero, como veremos

00:03:37.267 --> 00:03:39.231
es la forma que desee leer esta información:

00:03:39.231 --> 00:03:41.792
Si está recibiendo mala cobertura en el nivel de C0

00:03:41.792 --> 00:03:44.072
a continuación, tiene realmente muy mala cobertura

00:03:44.072 --> 00:03:46.082
Así que si no son amables de decisiones

00:03:46.082 --> 00:03:47.370
Este nivel simple de cobertura superficial

00:03:47.370 --> 00:03:50.021
a continuación, la prueba es probablemente deficiente

00:03:50.021 --> 00:03:51.916
C1 es el siguiente paso que

00:03:51.916 --> 00:03:53.719
Podríamos decir:

00:03:53.719 --> 00:03:55.198
Pues bien, tenemos que tener cada rama en ambas direcciones

00:03:55.198 --> 00:03:56.617
Por eso, cuando estamos haciendo esta declaración de "si"

00:03:56.617 --> 00:03:58.667
Tenemos que asegurarnos de que

00:03:58.667 --> 00:03:59.923
hacemos la "si x" parte de una vez

00:03:59.923 --> 00:04:05.137
y la parte "si no x" al menos una vez

00:04:05.137 --> 00:04:08.361
C1, usted puede aumentar con cobertura de decisión

00:04:08.361 --> 00:04:09.638
diciendo: bueno, si somos gonna…

00:04:09.638 --> 00:04:12.369
Si tenemos statments "si" donde la condición

00:04:12.369 --> 00:04:13.890
se compone de varios términos

00:04:13.890 --> 00:04:15.716
Tenemos que asegurarnos de que cada subexpresión

00:04:15.716 --> 00:04:17.972
ha sido evaluado en ambas direcciones

00:04:17.972 --> 00:04:19.678
En otras palabras, esto significa que

00:04:19.678 --> 00:04:22.411
Si vamos a fallar esta declaración de "si"

00:04:22.411 --> 00:04:24.348
Tenemos que asegurarnos de dejar al menos una vez

00:04:24.348 --> 00:04:26.448
porque fue falsa en al menos una vez y porque era falso z

00:04:26.448 --> 00:04:28.889
En otras palabras, cualquier subexpresión podría

00:04:28.889 --> 00:04:31.214
cambiar independientemente del resultado de la condición

00:04:31.214 --> 00:04:34.483
tiene que ejercerse en ambas direcciones

00:04:36.038 --> 00:04:38.523
Y, a continuación, de la que, sabes, muchas personas aspiran a

00:04:38.523 --> 00:04:41.264
pero hay desacuerdo sobre cuánto más valioso es

00:04:41.264 --> 00:04:42.834
es que tomar cada ruta a través del código

00:04:42.834 --> 00:04:45.537
Obviamente, esto es algo difícil porque

00:04:45.537 --> 00:04:48.331
tiende a ser exponencial en el número de condiciones

00:04:48.331 --> 00:04:53.088
y en general es difícil

00:04:53.088 --> 00:04:55.312
para evaluar si has tomado cada ruta a través del código

00:04:55.312 --> 00:04:57.015
Hay técnicas formales que se pueden utilizar

00:04:57.015 --> 00:04:58.833
que le diga dónde están los agujeros

00:04:58.833 --> 00:05:01.311
pero la conclusión es

00:05:01.311 --> 00:05:03.050
en las casas de software comerciales más

00:05:03.050 --> 00:05:04.891
diría yo, no hay un consenso completo

00:05:04.891 --> 00:05:06.708
en cuánto más valioso C2

00:05:06.708 --> 00:05:08.685
en comparación con C0 y C1

00:05:08.685 --> 00:05:10.138
Por eso, creo, con el propósito de nuestra clase