En la lección de hoy
exploraremos una forma de clasificar los tests.
Hay muchas maneras de en la clasificación de sus pruebas,
pero una clasificación muy común utilizada en la industria
gira en torno a tres tipos principales de pruebas en función de su alcance.
Estas son las pruebas unitarias, pruebas de características, y finalmente, las pruebas E2E.
Vamos a discutir estos diferentes tipos de pruebas
y sus respectivos propósitos en la jerarquía de pruebas.
Las pruebas unitarias, como su nombre indica se centran en unidades individuales de código.
Por ejemplo, funciones individuales, métodos, y, en el caso de los proyectos Vue,
incluso componentes de soporte más simples se prueban bajo pruebas unitarias.
Cuando una prueba unitaria falla,
el desarrollador sabrá con precisión el punto problemático en la base de código.
Yendo un poco más arriba, llegamos a las pruebas de características.
Ya no estamos hablando de unidades individuales de código por sí mismas,
sino de una característica específica que queremos que cumpla la aplicación.
Su ejecución dará lugar en múltiples elementos de la aplicación
interactuando entre sí.
Estas pruebas son todavía conscientes de algunos detalles de implementación,
pero no tanto como las pruebas unitarias.
Por ejemplo, incluso a nivel de pruebas de características,
nuestras pruebas harán invocaciones específicas para Vue.js
a través de Vue Test Utils.
Si una prueba de función falla,
la retroalimentación no necesariamente apuntará con precisión
al trozo de código problemático,
pero aún así investigación debería ser necesaria,
porque el alcance de las pruebas es todavía algo limitado.
Por último, tenemos las pruebas E2E.
En este nivel, estamos probando la aplicación como un todo,
en una simulación completa de las interacciones del usuario final.
Este es el tipo de prueba
que está en el nivel más alto de los tres que hemos cubierto hoy.
Al igual que tu usuario final no sabrá
que su sitio web se está ejecutando en Vue TypeScript,
sus pruebas E2E tampoco necesitan saberlo.
Por esa razón, de todas las tres pruebas que hemos cubierto,
esta es la que menos sabe
sobre la implementación de tu aplicación.
Dado que estos se están ejecutando en el nivel más alto,
si una prueba E2E falla, la razón detrás del fallo
podría estar en muchos lugares diferentes a lo largo de la aplicación.
Por esa razón, una investigación más larga podría ser necesaria
por parte del equipo de desarrollo.
Cada tipo de prueba es valioso y sirve para algo.
Creo que una buena manera de
para entender dónde cada uno de estos tipos de pruebas
es viéndolas en la práctica.
He creado una pequeña calculadora convertidora de peso.
Se supone que para convertir entre kilogramos y libras.
Por ejemplo, puedo convertir 100 kilogramos en libras,
y también puedo convertir 100 libras en kilogramos.
Como usted puede ser capaz de ver en este conjunto de pruebas de aquí,
Decidí que una manera para mí de manejar estas conversiones de peso
sería utilizar un objeto de datos para representar el peso.
Este objeto de datos es simplemente una clase TypeScript.
Pero en lo que quiero que te centres, sin embargo,
son las pruebas unitarias que escribí aquí.
Por ejemplo, escribí una prueba que me probaría
que puedo convertir de libras a kilogramos,
y también escribí otra prueba
que podría proporcionar un peso específico en kilogramos,
y espero obtener la correcta peso convertido en libras.
Estas pruebas aquí son sólo para este objeto de datos operando por sí mismo.
Le estoy dando algunos valores
y le pido que me devuelva como otra unidad de peso
y afirmando que estoy recibiendo el valor esperado.
En un nivel un poco más alto ahora,
podemos mirar en las pruebas de características que escribí para el componente vue.
Observa que en este punto
Estoy montando el componente vue
e interactuando con los diferentes controles
que están siendo renderizados en la página.
Así, por ejemplo, aquí,
Estoy escribiendo en la entrada de peso el valor de 100,
y estoy marcando la casilla de verificación libras.
Y entonces espero que me devuelva un valor específico,
en el elemento de entrada para el peso.
Esta prueba no sabe cómo estoy haciendo la conversión en sí,
y esto es bueno.
La prueba debe saber lo menos posible sobre los detalles de la implementación.
Clasifico esto como pruebas de características
porque describen características específicas
que la aplicación necesita cumplir.
Sin embargo, ten en cuenta que parte de la comunidad Vue.js
seguiría clasificando estas pruebas como pruebas unitarias.
Y desde esa perspectiva,
es porque esto es probar un componente vue aislado.
Tiendo a no preocuparme preocuparme demasiado por la semántica.
Todo lo que espero aquí es que podamos entender la idea
detrás de lo que estoy llamando las pruebas de características.
Por último, también quiero mostrar algunas pruebas E2E que he escrito.
Fíjate que aquí
También estoy probando historias de usuario para mi aplicación.
Pero ahora, la prueba ni siquiera sabe qué framework front-end estamos usando.
Como puedes ver aquí, para ejecutar estas pruebas,
estamos iniciando un servidor local y abriendo un navegador.
Y aquí, estamos visitando una página real en nuestra aplicación
y programáticamente interactuando con la página
como lo haría una persona real.
Por ejemplo, aquí, estoy visitando la página,
Voy a la entrada para el peso,
Voy a borrar la entrada, escribiendo 75,
y luego selecciono el botón libras y haciendo clic en él.
Por último, estoy verificando que tengo el peso de 165.35 libras
en mi entrada.
De los tres tipos de pruebas que hemos cubierto hoy,
este es el más lento y más intensivo en recursos.
Pero brilla sobre el terreno
que está más cerca de lo que el usuario experimentará realmente.
La TDD puede utilizarse técnicamente con cualquiera de estos niveles,
pero mi patrón preferido es conducir el comportamiento de la aplicación primero
a través de pruebas de características.
Cualquier recurso de ayuda que necesarios durante el desarrollo
puede tener su aplicación a través de pruebas unitarias.
Por último, las pruebas E2E son geniales
para proteger las historias de usuario más importantes
una vez que las pruebas de características ya están en su lugar.
Mi razonamiento detrás de esto
es que las pruebas de características están en este punto dulce
donde puedes escribir pruebas
que protegen las historias de usuario sin forzar estrategias de implementación específicas.
También son relativamente rápidos de ejecutar y escribir,
y en caso de fallos, todavía proporcionan retroalimentación
que puede ser lo suficientemente específico para el equipo de desarrollo
para entender cuál es la causa de la regresión muy rápidamente.
Estupendo. Ahora usted sabe las diferencias entre pruebas unitarias, de características y E2E.