Estoy trabajando en una aplicación con una gran lista vertical de componentes secundarios. Cada componente secundario usa React.memo y he creado optimizaciones para garantizar que no se vuelvan a procesar cuando se modifican otros componentes en la lista y se actualiza el estado más arriba en el árbol de componentes.
Esto está funcionando bien y tiene mejoras de rendimiento dramáticas, sin embargo, quiero escribir pruebas unitarias para evitar futuras regresiones a medida que las personas en el proyecto agregan más funcionalidades, accesorios, estado, etc.
Idealmente, me gustaría representar el componente principal y con algunos de estos componentes secundarios, y realizar una acción en uno que solo debería hacer que el componente principal y ese componente secundario se vuelvan a procesar. Luego me gustaría probar que los otros componentes secundarios no se vuelvan a renderizar. Esta será una prueba de seguridad para garantizar que las personas no realicen cambios que rompan el React.memo (funciones anónimas u objetos nuevos como accesorios, etc.).
Aquí hay una descripción aproximada de la jerarquía:
function Parent() { const [state, setState] = useState({}); const items = queryItems(); return ( <div> {items.map((item) => <Child key={item.id} item={item} setState={setState} />)} <div> ); } const Child = React.memo(function({item, setState}) { const handleClick = () => { // Does something to update state setState({something: 'changed'}); }; return ( <div> {item.title} <button onClick={handleClick} /> </div> ); }); Si alguien entrara y cambiara la lógica de .map a esto:
{items.map((item) => <Child key={item.id} item={item} setState={setState} otherProp={{}} />)} Ese objeto agregado como otherProp rompería el React.memo y haría que todos los elementos secundarios se vuelvan a procesar cada vez que el elemento principal se procesa. ¿Cómo puedo escribir una prueba para asegurarme de que fallará si alguien provoca una regresión como esta? (Tenemos broma, biblioteca de pruebas de reacción y enzimas disponibles)
Una cosa que puede intentar es envolver al niño en un HOC con un accesorio de contador para ver si representó al niño, sin embargo, no estoy seguro de que eso funcione con memo.
Puede probar el objeto simulado espía de jest, https://jestjs.io/docs/jest-object , sin embargo, nuevamente, no estoy seguro de que vaya a funcionar con memo porque podría desencadenar una nueva representación en el objeto simulado cuando no lo hubiera hecho hecho en el niño memo.
Es posible que deba considerar detenidamente si todavía está realizando pruebas unitarias cuando pasa a un ámbito de este tipo de pruebas. La optimización, el equilibrio de carga, las pruebas de estrés, cómo los componentes interactúan con otros e ideas similares caen en el ámbito de las pruebas de integración, como se menciona en el comentario a su pregunta. Idealmente, solo debería probar piezas de código o componentes reutilizables cuantificados y no cómo interactúan entre sí, pero nuevamente esa es una zona gris ya que el padre está relacionado con sus propios hijos. En este caso, sin embargo, creo que probar si se vuelve a renderizar o no, no es aplicable a las pruebas unitarias.
Creo que su mejor opción es simplemente confiar en que el niño no se volverá a procesar si le ha pasado los mismos accesorios y si se aplica la nota, en cuyo caso no tiene que preocuparse si se está volviendo a procesar, en su lugar puede pruebe si los accesorios que se le pasaron siguen siendo los mismos y, a través de eso, concluya que no se volverá a renderizar. Más bien pruebe algo como los accesorios en sí en lugar del renderizado.