9:59:59.000,9:59:59.000
y unir esas cosas

9:59:59.000,9:59:59.000
antes de ese plazo

9:59:59.000,9:59:59.000
haya terminado

9:59:59.000,9:59:59.000
Derecho

0:00:00.579,0:00:01.922
Así que nos pasamos un montón de tiempo

0:00:01.922,0:00:03.322
en el último par de conferencias

0:00:03.322,0:00:05.821
hablando sobre los diferentes tipos de pruebas

0:00:05.821,0:00:08.219
sobre la unidad de pruebas frente a pruebas de integración

0:00:08.219,0:00:10.102
acerca de cómo uso RSpec

0:00:10.102,0:00:12.495
realmente aislar las partes del código que desee probar

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

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

0:00:18.176,0:00:20.621
donde hemos estado usando pepino para activar las historias de usuario

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

0:00:22.953,0:00:25.610
Has visto pruebas en un par de diferentes niveles

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

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

0:00:29.924,0:00:33.011
y ver el panorama

0:00:33.011,0:00:34.956
Así que esto abarca una especie de material

0:00:34.956,0:00:37.007
abarca tres o cuatro secciones del libro

0:00:37.007,0:00:39.618
y quiero que acaban de golpear los puntos altos en Conferencia

0:00:39.618,0:00:41.461
Por lo tanto una pregunta surge

0:00:41.461,0:00:43.253
Estoy seguro de que ha llegado para todos ustedes

0:00:43.253,0:00:44.526
como ha estado haciendo deberes

0:00:44.526,0:00:45.695
es: "cuánto pruebas es suficiente?"

0:00:45.695,0:00:48.497
Y, lamentablemente, durante mucho tiempo

0:00:48.497,0:00:51.090
tipo de si esta pregunta en la industria

0:00:51.090,0:00:52.180
la respuesta fue básicamente

0:00:52.180,0:00:53.179
"Tenemos un plazo de envío

0:00:53.179,0:00:55.000
¿cuánto podemos hacer pruebas

0:00:55.000,0:00:56.667
eso es cuánto".

0:00:56.667,0:00:58.153
¿Verdad? Eso es lo que tienes tiempo.

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

0:01:00.024,0:01:01.118
Obviamente no es muy buena

0:01:01.118,0:01:02.549
¿Puede hacer un poco mejor, derecho?

0:01:02.549,0:01:03.702
Allí están algunas medidas estáticas

0:01:03.702,0:01:06.034
como el número de líneas de código tiene su app

0:01:06.034,0:01:08.216
y ¿cuántas líneas de pruebas tienes?

0:01:08.216,0:01:10.290
Y no es inusual en la industria

0:01:10.290,0:01:12.682
en una pieza de software comprobada

0:01:12.682,0:01:14.574
el número de líneas de pruebas

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

0:01:17.736,0:01:19.752
Así, entero múltiplos no son inusuales

0:01:19.752,0:01:21.843
Y creo que incluso para una especie de, ya saben,

0:01:21.843,0:01:23.229
código de investigación o trabajos

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

0:01:26.856,0:01:30.058
por lo tanto una veces y media la cantidad de código de prueba

0:01:30.058,0:01:32.249
como el código de la aplicación

0:01:32.249,0:01:34.221
Y una gran cantidad de sistemas de producción

0:01:34.221,0:01:35.277
donde realmente importa sobre pruebas

0:01:35.277,0:01:36.919
es mucho mayor que

0:01:36.919,0:01:38.155
Quizás una mejor pregunta

0:01:38.155,0:01:39.472
¿En lugar de decir: pruebas de cuánto es suficiente?

0:01:39.472,0:01:42.493
¿es preguntar: Qué buena es la prueba que estoy haciendo ahora?

0:01:42.493,0:01:44.351
¿Cómo profundo es?

0:01:44.351,0:01:45.565
Más adelante en este semestre

0:01:45.565,0:01:46.568
Profesor Sen hablará sobre

0:01:46.568,0:01:48.189
un poco más acerca de los métodos formales

0:01:48.189,0:01:50.857
y ordenar lo que es las fronteras de la prueba y depuración

0:01:50.857,0:01:52.686
Pero un par de cosas podemos hablar

0:01:52.686,0:01:54.073
basado en lo que ya sabe

0:01:54.073,0:01:57.744
es algunos conceptos básicos acerca de la cobertura de la prueba

0:01:57.744,0:01:59.550
Y aunque yo diría

0:01:59.550,0:02:01.017
ustedes saben, que hemos estado diciendo todo el tiempo

0:02:01.017,0:02:03.034
métodos formales, realmente no funcionan en grandes sistemas

0:02:03.034,0:02:05.330
Creo que esa declaración, en mi opinión personal

0:02:05.330,0:02:07.011
realmente es mucho menos cierto lo que solía ser

0:02:07.011,0:02:09.190
Creo que hay un número de lugares específicos

0:02:09.190,0:02:10.524
especialmente en pruebas y depuración

0:02:10.524,0:02:12.848
donde métodos formales son realmente avanzando rápido

0:02:12.848,0:02:15.756
y Koushik Sen es uno de los líderes que

0:02:15.756,0:02:17.944
Por lo que tendrás la oportunidad de conocer más acerca de que más tarde

0:02:17.944,0:02:21.437
pero parece por el momento, tipo de pan y mantequilla

0:02:21.437,0:02:22.734
es vamos a hablar de la medición de cobertura

0:02:22.734,0:02:24.475
porque es donde la goma cumple la carretera

0:02:24.475,0:02:26.204
en términos de cómo serán evaluados

0:02:26.204,0:02:28.631
Si estás haciendo esto de verdad

0:02:28.631,0:02:29.530
¿Qué es algunos aspectos básicos?

0:02:29.530,0:02:30.781
Aquí es una clase realmente simple que se puede utilizar

0:02:30.781,0:02:32.902
para hablar sobre diferentes formas de medir

0:02:32.902,0:02:34.801
¿cómo nuestra prueba cubre este código

0:02:34.801,0:02:36.632
y existen unos niveles diferentes

0:02:36.632,0:02:37.851
con terminologías diferentes

0:02:37.851,0:02:40.737
No es realmente universal a través de todas las casas de software

0:02:40.737,0:02:42.641
pero un común conjunto de terminología

0:02:42.641,0:02:43.647
que expone el libro

0:02:43.647,0:02:44.689
es que podríamos hablar de S0

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

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

0:02:50.452,0:02:52.150
Que es la cobertura de S0: no terriblemente profundo

0:02:52.150,0:02:54.688
Es un poco más estrictas S1

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

0:02:56.137,0:02:57.288
desde cada lugar que podría llamarse

0:02:57.288,0:02:58.820
Así que ¿qué significa eso?

0:02:58.820,0:03:00.076
Esto significa, por ejemplo

0:03:00.076,0:03:01.124
no basta con llamar a bar

0:03:01.124,0:03:02.952
Tiene que asegurarse de que hay que llamarlo

0:03:02.952,0:03:05.575
al menos una vez desde aquí

0:03:05.575,0:03:07.161
así como llamar una vez

0:03:07.161,0:03:10.370
desde cualquier función exterior podría llamar

0:03:10.370,0:03:12.820
C0 que es lo que mide SimpleCov

0:03:12.820,0:03:15.997
aquellos de ustedes que has metido SimpleCov funcionando

0:03:15.997,0:03:18.522
Básicamente dice que ha ejecutado cada declaración

0:03:18.522,0:03:20.045
ha tocado cada instrucción en el código una vez

0:03:20.045,0:03:22.483
Pero la advertencia de allí es que

0:03:22.483,0:03:25.587
condicionales realmente sólo cuentan como una sola instrucción

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

0:03:28.915,0:03:31.749
como tocó una de la otra rama

0:03:31.749,0:03:33.350
ha ejecutado el "si" declaración

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

0:03:35.670,0:03:37.267
Pero, como veremos

0:03:37.267,0:03:39.231
es la forma que desee leer esta información:

0:03:39.231,0:03:41.792
Si está recibiendo mala cobertura en el nivel de C0

0:03:41.792,0:03:44.072
a continuación, tiene realmente muy mala cobertura

0:03:44.072,0:03:46.082
Así que si no son amables de decisiones

0:03:46.082,0:03:47.370
Este nivel simple de cobertura superficial

0:03:47.370,0:03:50.021
a continuación, la prueba es probablemente deficiente

0:03:50.021,0:03:51.916
C1 es el siguiente paso que

0:03:51.916,0:03:53.719
Podríamos decir:

0:03:53.719,0:03:55.198
Pues bien, tenemos que tener cada rama en ambas direcciones

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

0:03:56.617,0:03:58.667
Tenemos que asegurarnos de que

0:03:58.667,0:03:59.923
hacemos la "si x" parte de una vez

0:03:59.923,0:04:05.137
y la parte "si no x" al menos una vez

0:04:05.137,0:04:08.361
C1, usted puede aumentar con cobertura de decisión

0:04:08.361,0:04:09.638
diciendo: bueno, si somos gonna…

0:04:09.638,0:04:12.369
Si tenemos statments "si" donde la condición

0:04:12.369,0:04:13.890
se compone de varios términos

0:04:13.890,0:04:15.716
Tenemos que asegurarnos de que cada subexpresión

0:04:15.716,0:04:17.972
ha sido evaluado en ambas direcciones

0:04:17.972,0:04:19.678
En otras palabras, esto significa que

0:04:19.678,0:04:22.411
Si vamos a fallar esta declaración de "si"

0:04:22.411,0:04:24.348
Tenemos que asegurarnos de dejar al menos una vez

0:04:24.348,0:04:26.448
porque fue falsa en al menos una vez y porque era falso z

0:04:26.448,0:04:28.889
En otras palabras, cualquier subexpresión podría

0:04:28.889,0:04:31.214
cambiar independientemente del resultado de la condición

0:04:31.214,0:04:34.483
tiene que ejercerse en ambas direcciones

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

0:04:38.523,0:04:41.264
pero hay desacuerdo sobre cuánto más valioso es

0:04:41.264,0:04:42.834
es que tomar cada ruta a través del código

0:04:42.834,0:04:45.537
Obviamente, esto es algo difícil porque

0:04:45.537,0:04:48.331
tiende a ser exponencial en el número de condiciones

0:04:48.331,0:04:53.088
y en general es difícil

0:04:53.088,0:04:55.312
para evaluar si has tomado cada ruta a través del código

0:04:55.312,0:04:57.015
Hay técnicas formales que se pueden utilizar

0:04:57.015,0:04:58.833
que le diga dónde están los agujeros

0:04:58.833,0:05:01.311
pero la conclusión es

0:05:01.311,0:05:03.050
en las casas de software comerciales más

0:05:03.050,0:05:04.891
diría yo, no hay un consenso completo

0:05:04.891,0:05:06.708
en cuánto más valioso C2

0:05:06.708,0:05:08.685
en comparación con C0 y C1

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