Y eso es suficiente sobre mí. Demos un paso atrás y recapitulemos sobre las pruebas. Entonces, las pruebas, el parámetro de las pruebas es el parámetro más esencial que utilizaremos para construir cualquier sistema de pruebas y cualquier aplicación, ¿verdad? Entonces, para este parámetro de pruebas, tenemos tres capas: prueba unitaria, prueba de integración y prueba de extremo a extremo. La prueba unitaria se considera la base más sólida para todas nuestras pruebas de aplicación, que incluye todas las lógicas independientes y probables que conforman nuestro sistema, nuestras aplicaciones. Luego, la prueba de integración es probar el flujo de datos entre diferentes módulos de lógica probables cuando los conectas juntos, para asegurarte de que nada se rompa en el medio. Y finalmente, la prueba de extremo a extremo es la más costosa, con muy pocas pruebas. Puedes ver en la parte superior del parámetro. Es costoso, pero también es muy importante simular la experiencia de los usuarios paso a paso sobre cómo interactúan con la aplicación antes de hacer la implementación.
Y así llegamos a la siguiente pregunta. ¿A qué pertenece la prueba de componentes? Hemos estado hablando mucho sobre la prueba de componentes, sobre cómo podemos hacerlo con Playwright, cómo lo hacemos con Cypress. Pero, ¿qué es la prueba de componentes y a qué pertenece? Bueno, la prueba de componentes en muchos aspectos tiene muchos significados diferentes. En el backend, simplemente significa un fragmento de código, un módulo, un bloque de código en el sistema que necesitas probar de forma independiente. Mientras tanto, en el frontend, se vuelve más complejo. Entonces, de hecho, la prueba de componentes se puede dividir en dos tipos. La prueba de componentes en pequeño, que es la prueba modular, o podemos llamarla prueba de unidad. La prueba de componentes en grande significa que estás validando un componente con la ayuda de otros componentes, como una galería, que depende de los componentes de elementos de la galería para renderizar y mostrar la lista completa de elementos. Lo que significa que cuando probamos este elemento de galería, no solo probamos el componente individual aislado del elemento de galería, lo siento, galería. Tenemos que probarlo junto con los elementos de la galería para ver si la entrada y salida de un componente serán necesarios para las pruebas. Otro componente vendrá sin problemas, y también debemos preocuparnos por la interacción del usuario, y así sucesivamente. Por eso, podemos decir que la prueba de componentes se divide en dos tipos. La prueba de componentes en pequeño, prueba de unidad. La prueba de componentes en grande, prueba de integración o prueba de extremo a extremo. En la prueba de extremo a extremo, realmente depende de cómo definas el flujo de tu prueba de componente individual que estás buscando.
Entonces, lo que significa en la pirámide, volvamos a la pregunta que hicimos antes, ¿a qué pertenece la prueba de componentes? En la pirámide de pruebas, es un área gris. De hecho, es un área gris entre la prueba de integración y la prueba de unidad. Realmente depende del escenario y los objetivos de las pruebas para decidir si la prueba de componentes que estás tratando de lograr es una prueba de integración o una prueba de unidad. Y eso nos lleva a nuestra próxima pregunta. ¿Cuándo vamos a escribir una prueba de unidad para el componente y cuándo vamos a escribir una prueba de integración para cada componente, o ambas? ¿Y qué tecnología debemos usar para cada escenario? Para eso, vamos a nuestra aplicación de demostración. Entonces, en nuestra aplicación de demostración, vamos a tener una aplicación muy simple, una tienda de pizzas, que permite a los usuarios agregar al carrito y luego actualizar el carrito, y también buscar y actualizar la URL. Para la aplicación de demostración, vamos a realizar la prueba, la comparación entre dos métodos. El primero es VTest con VueTestUtil, y el segundo es la prueba de componentes de Playwright.
Comments