¡Bienvenidos! Feliz de verlos en la sexta parte de mi serie de resúmenes de Vuejs Amsterdam Conference 2022, en la que comparto un resumen de todas las charlas con ustedes.

Puede leer mi serie de resúmenes de la JSWorld Conference 2022 (en cuatro partes) aquí , donde resumí todas las charlas del primer día. También puede encontrar las charlas anteriores de la conferencia Vue Amsterdam 2022 en mi blog.

(Recurrente) Introducción

Después de dos años y medio, JSWorld y Vue Amsterdam Conference volvieron al Theatre Amsterdam entre el 1 y el 3 de junio, y tuve la oportunidad de asistir a esta conferencia por primera vez. Aprendí muchas cosas, conocí a mucha gente maravillosa, hablé con grandes desarrolladores y la pasé muy bien. El primer día se llevó a cabo la JSWorld Conference, y el segundo y tercer día, la Vue Amsterdam.

La conferencia estuvo llena de información con grandes oradores, cada uno de los cuales me enseñó algo valioso. Todos querían compartir sus conocimientos e información con otros desarrolladores. Entonces pensé que sería genial si pudiera continuar compartiéndolo y ayudar a otros a usarlo.

Al principio, traté de compartir algunas notas o diapositivas, pero sentí que no era lo suficientemente bueno, al menos no tan bueno como lo que el orador compartió conmigo. Así que decidí volver a ver cada discurso, profundizar en ellos, buscar, tomar notas y combinarlos con sus diapositivas e incluso con sus palabras exactas en su discurso y luego compartirlo con ustedes para que lo que les comparto sea al menos al mismo nivel que lo que aprendí de ellos.

Un punto muy importante

Todo lo que lee durante estos pocos artículos es el resultado del esfuerzo y el tiempo del propio hablante, y solo he tratado de aprenderlos para poder convertirlos en estos artículos. Incluso muchas de las oraciones escritas en estos artículos son exactamente lo que dijeron o lo que escribieron en Diapositivas. Esto significa que si aprendes algo nuevo, es gracias a sus esfuerzos. (Entonces, si ven alguna información errónea, culpen a ellos, no a mí, ¿no? xD)

Por último, pero no menos importante, es posible que no profundice en todos los detalles técnicos o codificaciones en vivo en algunos de los discursos. Pero si está interesado y necesita más información, hágamelo saber e intentaré escribir un artículo más detallado por separado. Además, no olvide consultar su Twitter/Linkedin.

Aquí puede encontrar el programa de la conferencia.

¡Es una trampa (de prueba)! Dificultades comunes de las pruebas y cómo resolverlas

Ramona Schwering - Desarrolladora de software en shopware

"Es una trampa": una llamada o sentimiento con el que todos podemos estar familiarizados, no solo cuando se trata de Star Wars. Está señalando un momento repentino de darse cuenta de un peligro inminente.

Esta situación es una excelente alegoría de una realización desagradable en las pruebas. ¿Imagínese tener las mejores intenciones en lo que respecta a las pruebas, pero aún así terminar con pruebas que no le brindan ningún valor?

Pruebas que se sienten como un dolor para tratar?

Al escribir pruebas de interfaz, hay muchas trampas en el camino. En resumen, pueden conducir a una pésima capacidad de mantenimiento, un tiempo de ejecución lento y, en el peor de los casos, pruebas en las que no puede confiar.

Pero el peor punto de dolor son esas pruebas que le dan un nuevo valor y resultado porque son escamosas. Tienes una compilación que a veces pasa y otras veces falla y no hiciste nada en el medio.

Puntos de dolor

Puede estar seguro de que las pruebas tienen muchos beneficios y ventajas, pero todas esas cosas maravillosas pueden verse eclipsadas por puntos débiles causados por varias razones. Todas las cosas que hiciste con las mejores intenciones pero que a la larga o incluso antes resultaron dolorosas o agotadoras.

Por ejemplo, las pruebas lentas pueden acabar con la diversión. Imagine que tiene su solicitud de extracción y desea que se fusione, pero debe esperar horas o tal vez días para que finalmente se complete la canalización.

Peor aún son las pruebas que son dolorosas de mantener. Piensas en tu yo pasado y te preguntas: ¿Qué hiciste con esta prueba? ¿Cuál fue el propósito? ¿Qué pensaste sobre eso? U otros miembros del equipo que te hacen preguntas sobre lo que hiciste en el pasado y no tienes ni idea.

Pero el peor punto de dolor son esas pruebas que le dan un nuevo valor y resultado porque son escamosas. Tienes una compilación que a veces pasa y otras veces falla y no hiciste nada en el medio.

Pruebas simples

No tiene que ser de esta manera. Una de las mentalidades y reglas de oro más importantes en las mejores prácticas de prueba de JavaScript es Simple.

Las pruebas deben diseñarse claras y simples en todos los casos. En las pruebas unitarias, las pruebas de integración y las pruebas de extremo a extremo, manténgalo estúpidamente simple.

Nuestro objetivo debe ser que uno sea capaz de comprender su prueba y obtener su intención al instante sin pensar en ello.

Intente apuntar a un diseño de prueba plano, lo que significa probar solo lo necesario y usar pocas o ninguna abstracción.

trampas

Veamos la primera trampa.

 describe('deprecated.plugin', () => { it('should throw error',() => { … }); });

Debería arrojar un error si el complemento obsoleto está en uso.

Cuando miras el título, debería arrojar un error, no sabes lo que quiere lograr. Pero la regla de oro dice que debes saber al instante lo que está haciendo.

Podemos hacerlo más comprensible con la “Regla de las Tres Partes”. El título de la prueba debe contener tres cosas:

1. que se esta probando
2. En qué circunstancias se debe probar
3. Cuál es el resultado esperado

Con esta regla en mente, así es como se verá nuestra prueba:

 describe('deprecated.plugin', () => { it('Property: Should throw an errorif the deprecated prop is used', () => { … }); });

La siguiente trampa puede ser la estructura de prueba:

 describe('Context menu', () => { it('should open the context menu on click', async () => { const wrapper = createWrapper(); expect(wrapper.vm).toBeTruthy(); await wrapper.trigger('click'); const selector = '.sw-context-menu'; expect(wrapper.find(selector).isVisible()).toBeTruthy(); }); });

En este caso, las declaraciones, acciones y afirmaciones están escritas por todas partes sin una estructura clara. Especialmente en pruebas más grandes, esto puede ser un gran dolor. Podemos hacerlo más estructurado con Patrón AAA. Divide su prueba en tres partes:

1. Organizar: Todo lo referente a la configuración del escenario que la prueba pretende simular.
2. Acciones: ejecutar su unidad en la prueba y seguir los pasos para llegar al estado de resultados.
3. Afirmar: donde puede hacer las afirmaciones y verificar su escenario de prueba.

Así es como se ve nuestra prueba con el patrón AAA:

 describe('Context menu', () => { it('should open the context menu on click', () => { // Arrange const wrapper = createWrapper(); const selector = '.sw-context-menu'; // Act await wrapper.trigger('click'); // Assert expect(wrapper.vm).toBeTruthy(); expect(wrapper.find(selector).isVisible()).toBeTruthy(); }); });

¡Esto se ve mucho mejor!

Pero hay un problema. Piense en nuestro caso de prueba. Es un menú contextual y está oculto por defecto. Así que tenemos que abrirlo para interactuar con él. Pero significa que debemos hacer una afirmación para asegurarnos de que esté abierta antes del acto. ¿No destruye el patrón?

Si estamos probando el DOM, a veces necesitamos verificar los estados antes y después. Así que echemos un vistazo a este patrón desde otra perspectiva.

• …organizar mi prueba == lo que me dan .
• …actúa en mi prueba == cuando pasa algo.
• … afirmar los resultados == algo sucede , entonces esto es lo que espero como resultado.

Este es un patrón tomado del desarrollo impulsado por el comportamiento: Dado - Cuando - Entonces

Nuestra prueba anterior con el uso de este patrón:

 describe('Context menu', () => { it('should open the context menu on click', () => { // Given const contextButtonSelector = 'sw-context-button'; const contextMenuSelector = '.sw-context-menu'; // When let contextMenu = wrapper.find(contextMenuSelector); expect(contextMenu.isVisible()).toBe(false); const contextButton = wrapper.find(contextButtonSelector); await contextButton.trigger('click'); // Then contextMenu = wrapper.find(contextMenuSelector); expect(contextMenu.isVisible()).toBe(true); }); });

Pruebas E2E

Evite el uso de marcadores de posición y use nombres realistas tanto como sea posible.

 it('should create and read product', () => { … cy.get('.sw-field—product-name').type('T-Shirt Ackbar'); cy.get('.sw-select-product__select_manufacturer') .type('Space Company'); … });

Si no quiere encontrar miles de nombres, tal vez pueda usar faker u otras herramientas para generar algunos datos ficticios, o si está de acuerdo con las leyes y su proyecto, impórtelos desde el estado de producción. Solo asegúrese de que su prueba sea comprensible y fácil de leer y que sepa lo que hace.

Echemos un vistazo a la misma prueba para la siguiente trampa, que son los selectores.

Si refactoriza su aplicación y cambia algunas clases, lo cual es común, esto podría causar que su prueba falle y, en este caso, la prueba falla sin que haya un error presente en su aplicación, lo que se denomina falso negativo y no brinda un informe confiable de su aplicación porque no está rota, solo cambió su implementación.

¡Mira los selectores que debes! En otras palabras, no debe probar los detalles de implementación. En su lugar, piense en usar cosas a las que un usuario llamaría la atención y navegar por su aplicación. Por ejemplo, algún texto dentro de su página. Aún mejor, use selectores que no sean tan propensos a cambiar, como los atributos de datos. Incluso puede llamarlo, por ejemplo, para cypress data-cy=”submit” para saber al instante que está destinado a la prueba.

Por último, pero no menos importante, no utilice tiempos de espera fijos.

 Cypress.Commands.add('typeSingleSelect', { prevSubject: 'element', }, (subject, value, selector) => { … cy.wait(500); cy.get(`${selector} input`) .type(value); });

Por un lado, eso puede ralentizar demasiado su prueba si un caso de prueba se ejecutará tantas veces. Puede ser aún peor cuando su aplicación se usa en un hardware más débil. En este caso, es posible que necesite más de esa corrección de 500 ms.

Hay algunas soluciones para eso, por ejemplo, esperar los cambios en la interfaz de usuario, como que desaparezca un control giratorio para cargar o que se detenga una animación o que aparezca algo.

O incluso mejor, espera las solicitudes y respuestas de la API.

Las pruebas están allí como un asistente para usted, no como un obstáculo. Deben sentirse como una rutina, no como resolver una fórmula matemática compleja.

Fin de la Sexta Charla

Espero que hayas disfrutado esta parte y que pueda ser tan valiosa para ti como lo fue para mí. Durante los próximos días, compartiré con ustedes el resto de las charlas. Manténganse al tanto…

También publicado aquí .