He estado entrevistando durante bastante tiempo. Lo que se destacó en este doloroso proceso fue que la entrevista estaba condenada al fracaso si es que se planteaba la cuestión de las pruebas. Esto se debe a que mis experiencias han sido principalmente en el desarrollo de frontend y las dos empresas en las que he estado eran muy pobres en las pruebas de frontend.

--- Salta si quieres ir directamente a la discusión ---

Mi falta fue, en cierto sentido, un subproducto de la cultura de la industria. Las pruebas frontend siempre han existido, pero hace una década, la estructura de la empresa separaba las preocupaciones sobre las pruebas del proceso de desarrollo. Así que teníamos un equipo de control de calidad dedicado que escribiría pruebas E2E/automatizadas para nosotros, los desarrolladores. Entonces las pruebas ni siquiera estaban en la descripción del trabajo. Además, la desafortunada verdad de las pequeñas empresas emergentes es que la entrega siempre está por encima de todo lo demás, por lo que, dado que las pruebas obstaculizan la productividad, los desarrolladores no las probamos. Ni siquiera teníamos ninguna biblioteca de prueba (Jasmine/Mocha/PhantomJS...) instalada en el repositorio.

Conseguí mi segundo trabajo en una empresa mucho más grande (¿el equipo de plataforma de consumo tenía como 150 desarrolladores?). Sin embargo, en esencia, no hubo pruebas. Cada equipo (equipos divididos por características como pago, lealtad, registro...) nuevamente tenía miembros de control de calidad dedicados que escribirían esas pruebas E2E. Una vez que se estableció esa cultura y se eliminó el control de calidad del presupuesto, nadie los recogió porque no había nadie de quien aprenderlo. Intenté realizar algunas pruebas E2E para nuestro equipo, pero el código que quedó ni siquiera era funcional y estaba lleno de errores obvios (muchos WTF). Combinado con plazos ajustados OTRA VEZ, las pruebas se retrasaron. La única vez que la gente habló de pruebas fue para funciones de utilidad y ganchos de reacción personalizados.

--- comienza la discusión ---

Al estar plagado de la cultura de no realizar pruebas, al menos tengo que pensar en algo que pueda decir durante las entrevistas sobre las pruebas de manera abstracta. Me saltaré las tonterías habituales de no probar estilos o implementar lo que sea.

Siéntete libre de agregar algo a la discusión. ¡Esto afecta al menos a 300 de mis compañeros de trabajo anteriores!

1.) probar estados globales:
En mi experiencia, una de las características más retorcidas es el tipo de comportamiento "si esto sucede, lo haremos automáticamente". Por ejemplo, una aplicación que tenía era un panel de visualización de gráficos que era muy configurable. Un cambio de configuración puede hacer que otras configuraciones también cambien, dependiendo de los datos devueltos y otros. Algunos efectos secundarios de la configuración no son sencillos. Por lo tanto, querrá probar los cambios de configuración automáticos y si el estado es persistente/sin cambios/consistente en todos los ámbitos. Entonces, si realiza pruebas sobre este tipo de comportamiento, alinearlo con el equipo de PM, gerentes, diseño y control de calidad es inmensamente valioso.

2.) no dedique mucho tiempo a probar la integridad de la entrada de la interfaz de usuario:
Veo bastantes tutoriales que hablan sobre probar entradas, como cuando escribo "taylor swift" en la barra de búsqueda y presiono Intro, nuestra función de búsqueda obtendrá taylor swift como entrada.

Esto es completamente inútil. Si su enlace de datos está roto, será muy obvio que debería haberlo detectado usted mismo durante el desarrollo o no se puede probar automáticamente porque algo estaba obstaculizando la funcionalidad, como un div invisible encima de la barra de búsqueda para que los usuarios no puedan escribir en la búsqueda.

si te pagan por líneas de código, adelante :)

3.) Aunque es deseable probar los insumos como efecto secundario de los insumos:
Al contrario del número 2, querrás probar llamadas funcionales que son completamente efectos secundarios de la interacción del usuario. Por ejemplo, cuando el usuario hace clic en un botón, se debe llamar a una solicitud para registrar esta acción del usuario para el análisis de datos. Este tipo de efecto secundario, que está completamente separado de la funcionalidad principal, debe probarse automáticamente para que algunos cambios no intencionales no nos tomen desprevenidos. Los efectos secundarios secundarios pueden ser esenciales para otros equipos; yo estuve en uno de esos otros equipos :D

Entonces, ¿cómo se diseñan estos requisitos de prueba?
analicemos la arquitectura frontend: MVC (puedes decir que eres MVVM o lo que sea, realmente no importa).

V - view (html/jsx): Esto es excelente para pruebas de navegadores E2E/sin encabezado y es un estándar de la industria.

C - controlador (lógica de negocios): dedique algún tiempo a asegurarse de que las funciones sean correctas. Por ejemplo, si tiene/resume funciones puras, ¿el proceso de entrada-salida esperado sigue intacto? Algo estándar de la industria, pero la gente no suele molestarse en convertir funciones con estado en funciones puras y pruebas.

M - modelo (llamadas/estados de API): esto es en lo que quiero centrarme más. sus estados (no renderizados) deben ser globales y únicos por concepto. No es una idea nueva, ya que Redux lo es básicamente. Sin embargo, no es necesario que sea Flux para nuestros propósitos de prueba. Puede tener átomos jotai pero puede codificar un contenedor para poder exponer sus funciones de configuración centralizadas para pruebas.

se debe hacer algo similar en sus llamadas api/bibliotecas de terceros. Debe ser global y único para que pueda probar con confianza "cuando hago esto, se realiza una llamada a la API principal/no principal en la aplicación". Esto se hace de forma rutinaria, según mi experiencia limitada, en aplicaciones backend. También debería hacerse en aplicaciones frontend.

¿Cómo suena esto? Estoy seguro de que alguien ya hace esto, ¿cuál es tu experiencia? ¿Qué se puede mejorar? Me encantaría saber de personas que afirman que las pruebas de interfaz van más allá de E2E/navegador sin cabeza y pruebas unitarias simples y alucinantes.