Return to Video

5.8 - 5.11 - Coverage, Unit vs. Integration Tests, Other Testing Concepts, and Perspectives

  • 0:01 - 0:02
    Así que nos pasamos un montón de tiempo
  • 0:02 - 0:03
    en el último par de conferencias
  • 0:03 - 0:06
    hablando sobre los diferentes tipos de pruebas
  • 0:06 - 0:08
    sobre la unidad de pruebas frente a pruebas de integración
  • 0:08 - 0:10
    acerca de cómo uso RSpec
  • 0:10 - 0:12
    realmente aislar las partes del código que desee probar
  • 0:12 - 0:15
    tienes además, sabes, porque de deberes 3,
  • 0:15 - 0:18
    y otra cosas, que hemos estado haciendo BDD,
  • 0:18 - 0:21
    donde hemos estado usando pepino para activar las historias de usuario
  • 0:21 - 0:23
    en esencia, pruebas de integración y aceptación
  • 0:23 - 0:26
    Has visto pruebas en un par de diferentes niveles
  • 0:26 - 0:28
    Y la meta aquí es una especie de hacer algunas observaciones
  • 0:28 - 0:30
    ustedes saben, vamos a respaldar un poco
  • 0:30 - 0:33
    y ver el panorama
  • 0:33 - 0:35
    Así que esto abarca una especie de material
  • 0:35 - 0:37
    abarca tres o cuatro secciones del libro
  • 0:37 - 0:40
    y quiero que acaban de golpear los puntos altos en Conferencia
  • 0:40 - 0:41
    Por lo tanto una pregunta surge
  • 0:41 - 0:43
    Estoy seguro de que ha llegado para todos ustedes
  • 0:43 - 0:45
    como ha estado haciendo deberes
  • 0:45 - 0:46
    es: "cuánto pruebas es suficiente?"
  • 0:46 - 0:48
    Y, lamentablemente, durante mucho tiempo
  • 0:48 - 0:51
    tipo de si esta pregunta en la industria
  • 0:51 - 0:52
    la respuesta fue básicamente
  • 0:52 - 0:53
    "Tenemos un plazo de envío
  • 0:53 - 0:55
    ¿cuánto podemos hacer pruebas
  • 0:55 - 0:57
    eso es cuánto".
  • 0:57 - 0:58
    ¿Verdad? Eso es lo que tienes tiempo.
  • 0:58 - 1:00
    Por lo tanto, ustedes saben, eso de voltear un poco
  • 1:00 - 1:01
    Obviamente no es muy buena
  • 1:01 - 1:03
    ¿Puede hacer un poco mejor, derecho?
  • 1:03 - 1:04
    Allí están algunas medidas estáticas
  • 1:04 - 1:06
    como el número de líneas de código tiene su app
  • 1:06 - 1:08
    y ¿cuántas líneas de pruebas tienes?
  • 1:08 - 1:10
    Y no es inusual en la industria
  • 1:10 - 1:13
    en una pieza de software comprobada
  • 1:13 - 1:15
    el número de líneas de pruebas
  • 1:15 - 1:18
    ir mucho más allá del número de líneas de código
  • 1:18 - 1:20
    Así, entero múltiplos no son inusuales
  • 1:20 - 1:22
    Y creo que incluso para una especie de, ya saben,
  • 1:22 - 1:23
    código de investigación o trabajos
  • 1:23 - 1:27
    una relación de ustedes saben, tal vez 1.5 no es razonable
  • 1:27 - 1:30
    por lo tanto una veces y media la cantidad de código de prueba
  • 1:30 - 1:32
    como el código de la aplicación
  • 1:32 - 1:34
    Y una gran cantidad de sistemas de producción
  • 1:34 - 1:35
    donde realmente importa sobre pruebas
  • 1:35 - 1:37
    es mucho mayor que
  • 1:37 - 1:38
    Quizás una mejor pregunta
  • 1:38 - 1:39
    ¿En lugar de decir: pruebas de cuánto es suficiente?
  • 1:39 - 1:42
    ¿es preguntar: Qué buena es la prueba que estoy haciendo ahora?
  • 1:42 - 1:44
    ¿Cómo profundo es?
  • 1:44 - 1:46
    Más adelante en este semestre
  • 1:46 - 1:47
    Profesor Sen hablará sobre
  • 1:47 - 1:48
    un poco más acerca de los métodos formales
  • 1:48 - 1:51
    y ordenar lo que es las fronteras de la prueba y depuración
  • 1:51 - 1:53
    Pero un par de cosas podemos hablar
  • 1:53 - 1:54
    basado en lo que ya sabe
  • 1:54 - 1:58
    es algunos conceptos básicos acerca de la cobertura de la prueba
  • 1:58 - 2:00
    Y aunque yo diría
  • 2:00 - 2:01
    ustedes saben, que hemos estado diciendo todo el tiempo
  • 2:01 - 2:03
    métodos formales, realmente no funcionan en grandes sistemas
  • 2:03 - 2:05
    Creo que esa declaración, en mi opinión personal
  • 2:05 - 2:07
    realmente es mucho menos cierto lo que solía ser
  • 2:07 - 2:09
    Creo que hay un número de lugares específicos
  • 2:09 - 2:11
    especialmente en pruebas y depuración
  • 2:11 - 2:13
    donde métodos formales son realmente avanzando rápido
  • 2:13 - 2:16
    y Koushik Sen es uno de los líderes que
  • 2:16 - 2:18
    Por lo que tendrás la oportunidad de conocer más acerca de que más tarde
  • 2:18 - 2:21
    pero parece por el momento, tipo de pan y mantequilla
  • 2:21 - 2:23
    es vamos a hablar de la medición de cobertura
  • 2:23 - 2:24
    porque es donde la goma cumple la carretera
  • 2:24 - 2:26
    en términos de cómo serán evaluados
  • 2:26 - 2:29
    Si estás haciendo esto de verdad
  • 2:29 - 2:30
    ¿Qué es algunos aspectos básicos?
  • 2:30 - 2:31
    Aquí es una clase realmente simple que se puede utilizar
  • 2:31 - 2:33
    para hablar sobre diferentes formas de medir
  • 2:33 - 2:35
    ¿cómo nuestra prueba cubre este código
  • 2:35 - 2:37
    y existen unos niveles diferentes
  • 2:37 - 2:38
    con terminologías diferentes
  • 2:38 - 2:41
    No es realmente universal a través de todas las casas de software
  • 2:41 - 2:43
    pero un común conjunto de terminología
  • 2:43 - 2:44
    que expone el libro
  • 2:44 - 2:45
    es que podríamos hablar de S0
  • 2:45 - 2:47
    donde sólo podría significar que has llamado cada método una vez
  • 2:47 - 2:50
    Así que ya sabéis, si llame foo, y se llama bar
  • 2:50 - 2:52
    Que es la cobertura de S0: no terriblemente profundo
  • 2:52 - 2:55
    Es un poco más estrictas S1
  • 2:55 - 2:56
    se podría decir, que estamos llamando cada método
  • 2:56 - 2:57
    desde cada lugar que podría llamarse
  • 2:57 - 2:59
    Así que ¿qué significa eso?
  • 2:59 - 3:00
    Esto significa, por ejemplo
  • 3:00 - 3:01
    no basta con llamar a bar
  • 3:01 - 3:03
    Tiene que asegurarse de que hay que llamarlo
  • 3:03 - 3:06
    al menos una vez desde aquí
  • 3:06 - 3:07
    así como llamar una vez
  • 3:07 - 3:10
    desde cualquier función exterior podría llamar
  • 3:10 - 3:13
    C0 que es lo que mide SimpleCov
  • 3:13 - 3:16
    aquellos de ustedes que has metido SimpleCov funcionando
  • 3:16 - 3:19
    Básicamente dice que ha ejecutado cada declaración
  • 3:19 - 3:20
    ha tocado cada instrucción en el código una vez
  • 3:20 - 3:22
    Pero la advertencia de allí es que
  • 3:22 - 3:26
    condicionales realmente sólo cuentan como una sola instrucción
  • 3:26 - 3:29
    Así que, si usted, no importa qué rama de este "si" tomó
  • 3:29 - 3:32
    como tocó una de la otra rama
  • 3:32 - 3:33
    ha ejecutado el "si" declaración
  • 3:33 - 3:36
    Así que incluso C0 es todavía, ustedes saben, excedente de superficial
  • 3:36 - 3:37
    Pero, como veremos
  • 3:37 - 3:39
    es la forma que desee leer esta información:
  • 3:39 - 3:42
    Si está recibiendo mala cobertura en el nivel de C0
  • 3:42 - 3:44
    a continuación, tiene realmente muy mala cobertura
  • 3:44 - 3:46
    Así que si no son amables de decisiones
  • 3:46 - 3:47
    Este nivel simple de cobertura superficial
  • 3:47 - 3:50
    a continuación, la prueba es probablemente deficiente
  • 3:50 - 3:52
    C1 es el siguiente paso que
  • 3:52 - 3:54
    Podríamos decir:
  • 3:54 - 3:55
    Pues bien, tenemos que tener cada rama en ambas direcciones
  • 3:55 - 3:57
    Por eso, cuando estamos haciendo esta declaración de "si"
  • 3:57 - 3:59
    Tenemos que asegurarnos de que
  • 3:59 - 4:00
    hacemos la "si x" parte de una vez
  • 4:00 - 4:05
    y la parte "si no x" al menos una vez
  • 4:05 - 4:08
    C1, usted puede aumentar con cobertura de decisión
  • 4:08 - 4:10
    diciendo: bueno, si somos gonna…
  • 4:10 - 4:12
    Si tenemos statments "si" donde la condición
  • 4:12 - 4:14
    se compone de varios términos
  • 4:14 - 4:16
    Tenemos que asegurarnos de que cada subexpresión
  • 4:16 - 4:18
    ha sido evaluado en ambas direcciones
  • 4:18 - 4:20
    En otras palabras, esto significa que
  • 4:20 - 4:22
    Si vamos a fallar esta declaración de "si"
  • 4:22 - 4:24
    Tenemos que asegurarnos de dejar al menos una vez
  • 4:24 - 4:26
    porque fue falsa en al menos una vez y porque era falso z
  • 4:26 - 4:29
    En otras palabras, cualquier subexpresión podría
  • 4:29 - 4:31
    cambiar independientemente del resultado de la condición
  • 4:31 - 4:34
    tiene que ejercerse en ambas direcciones
  • 4:36 - 4:39
    Y, a continuación, de la que, sabes, muchas personas aspiran a
  • 4:39 - 4:41
    pero hay desacuerdo sobre cuánto más valioso es
  • 4:41 - 4:43
    es que tomar cada ruta a través del código
  • 4:43 - 4:46
    Obviamente, esto es algo difícil porque
  • 4:46 - 4:48
    tiende a ser exponencial en el número de condiciones
  • 4:48 - 4:53
    y en general es difícil
  • 4:53 - 4:55
    para evaluar si has tomado cada ruta a través del código
  • 4:55 - 4:57
    Hay técnicas formales que se pueden utilizar
  • 4:57 - 4:59
    que le diga dónde están los agujeros
  • 4:59 - 5:01
    pero la conclusión es
  • 5:01 - 5:03
    en las casas de software comerciales más
  • 5:03 - 5:05
    diría yo, no hay un consenso completo
  • 5:05 - 5:07
    en cuánto más valioso C2
  • 5:07 - 5:09
    en comparación con C0 y C1
  • 5:09 - 5:10
    Por eso, creo, con el propósito de nuestra clase
  • Not Synced
    y unir esas cosas
  • Not Synced
    antes de ese plazo
  • Not Synced
    haya terminado
  • Not Synced
    Derecho
Title:
5.8 - 5.11 - Coverage, Unit vs. Integration Tests, Other Testing Concepts, and Perspectives
Video Language:
English

Spanish subtitles

Incomplete

Revisions

Our website uses cookies for analysis purposes.