Cuando se trata de probar código de bibliotecas, el enfoque de la (generalmente increíble) "Testing Library" rápidamente alcanza sus limitaciones: A menudo necesitamos probar rutas de código activas para garantizar garantías adicionales, como un orden específico de cambios en el DOM o un número particular de renders.
En cuanto comenzamos a agregar Suspense a la imagen, incluso se vuelve casi filosófico:
- ¿Cómo contamos un renderizado que se suspende inmediatamente y cómo lo distinguimos de un renderizado "confirmado"?
- ¿Cómo sabemos qué partes del árbol de componentes se volvieron a renderizar?
En la base de código de Apollo Client, estamos utilizando el React Profiler para crear un flujo de eventos de renderizado, lo que nos permite cambiar a un método de prueba basado en streams.
Después de probar este enfoque internamente durante un año, lo hemos lanzado en una biblioteca que queremos presentar al mundo.
También echaré un vistazo breve a otros problemas "relacionados con las pruebas" que están muy fuera de lo normal que hemos encontrado y compartir nuestras soluciones:
Cómo probar bibliotecas que agrupan diferentes códigos para React Server Components, ejecuciones de SSR en streaming y el navegador: Pruebas de tus campos de `exports` cada vez más complejos y asegurando que todos esos entornos exporten la forma de paquete que esperas.
Incluso echaremos un vistazo breve a cómo renderizar componentes de React en diferentes entornos para probarlos de forma aislada, ya sea en Server Components, Streaming SSR o simulando la hidratación de streams en el navegador.
This talk has been presented at React Advanced 2024, check out the latest edition of this React Conference.
Comments