Así que cuando llegamos a este caso 5, y eventualmente creo que es el caso 7, las cosas se ponen un poco más interesantes. Porque la pregunta que hice a las personas en estas entrevistas fue muy simple. ¿Podrías simplemente decirme cómo es tu stack de pruebas y qué tipo de pruebas estás escribiendo? ¿Cómo pruebas? Y creo que con el caso 5, es donde escuché por primera vez a la gente mencionar mock service worker. He estado usando mock service worker durante años. Lo abordaremos en esta charla. Pero esta es la primera empresa que me dijo, sí, tenemos Jest y React Testing Library para integración, Playwright para extremo a extremo, pero ahora también estamos usando mock service worker y una herramienta de simulación personalizada para simular nuestras solicitudes de red y otras. Caso 6, Jest y React Testing Library para integración unitaria. Y el caso 7 fue en realidad la primera persona en mencionar el análisis estático. Si estamos hablando del trofeo de pruebas, del cual hablaremos en un momento, el análisis estático es una gran parte de él. Y en este caso 7, están usando TypeScript y ESLint para hacer algo de análisis estático. VTest y React Testing Library para integración unitaria, y Playwright para extremo a extremo. Finalmente, para el caso 8, tenemos Cypress para extremo a extremo, Enzyme y React Testing Library para integración unitaria, y MSW con una herramienta de simulación personalizada, y una herramienta de simulación personalizada. Así que, este es un poco de resumen que abarca 8 empresas diferentes en 8 contextos diferentes. Y es algo muy interesante cuando estaba haciendo esta charla, porque ahora, cuando nos han enseñado el trofeo de pruebas y Kent Cedald nos ha explicado esto, y hemos aprendido esto en los últimos años, siempre pensamos en estos 4 temas, extremo a extremo, integración, unidad, estático, aunque un par de ellos se han vuelto un poco confusos a lo largo de los años, estos han sido los puntos de prueba que nos mantienen seguros. Así que pensé, está bien, usemos estos 4 puntos, el análisis estático, la integración unitaria, y el extremo a extremo para ver cómo estamos haciendo pruebas y cuál es el estándar actual para usar estas cosas.
Así que comencemos con el análisis estático. Comencemos desde abajo y subamos desde allí. Bueno, para sorpresa de nadie, TypeScript y ESLint siguen siendo el estándar para hacer análisis estático. Están más que probados, son resistentes a la batalla, y no veo a nadie diciendo que no quieren usarlos. Si tuviera que darte algo para tener en cuenta y mantener bajo tu radar es revisar Biome y OXC. Hay algunos desarrollos interesantes sucediendo allí desde una perspectiva de análisis estático, y de hecho he visto a un par de personas migrando de ESLint a Biome ya, y algunas organizaciones, así que están aquí, ya están dando a algunas personas decisiones diferentes y pruebas diferentes, así que esta es básicamente mi análisis para la parte de análisis estático.
Ahora, pasemos un poco más de tiempo hablando sobre las pruebas de unidad e integración, porque esta es la que creo que más nos emociona, digamos emocionados. Para eso, quería hacer una línea de tiempo, porque, bueno, hace un par de años estábamos escribiendo pruebas, hace un par de años, hace diez años más o menos, aquí es donde estábamos. Teníamos un montón de pruebas usando Karma y estábamos usando Jasmine, y todas estas eran pruebas de componentes. Estas pruebas se ejecutan en un navegador real, pero teníamos un par de problemas con esto. En primer lugar, estas pruebas no siempre eran confiables, eran un poco inestables, los navegadores siempre se estaban bloqueando, y no hablemos de cómo demonios podíamos llevar esto a una canalización CI-CD. Así que hicimos una transición, y esta transición significó, está bien, ahora no queremos ejecutar cosas en un entorno de navegador, queremos simular un entorno de navegador en un entorno basado en node, así que surgimos con JestDOM, y sobre JestDOM, teníamos Jest, y lo emparejamos con Enzyme, como una biblioteca de pruebas, para escribir nuestras pruebas. Y aquí es donde estábamos alrededor de 2017, 2018, pero en 2018, creo, es cuando algo cambió, y me gustaría llamarlo la falacia del backend y el dolor de la categorización, porque esto es lo que sucedió en 2018. El famoso tweet que cambió la forma en que hacíamos pruebas en el frontend, en el mundo de JavaScript. Cuanto más se parezcan tus pruebas a la forma en que se usa tu software, más confianza pueden darte.
Comments