Mocks - ¡no muerdas!
Están diseñados para ayudarlo a crear pruebas más simples y confiables. En esta serie de artículos, le mostraré los patrones en los que confío al burlarme (o "cortar") los componentes de React.
Este es un buen ejemplo de un talón de componente. Yo uso
jest.mock, que veremos con más detalle a continuación.
jest.mock("../src/PostContent", () => ({
PostContent: jest.fn(() => (
<div data-testid="PostContent" />
))
}))Un código auxiliar típico de un componente de React no debería parecer más complicado. Tenga en cuenta el valor de código auxiliar muy simple (
div) y un atributo data-testidque nos facilita encontrar la instancia renderizada en el DOM. Por convención, el identificador de prueba utilizado debe coincidir con el nombre del componente. En este caso, lo es PostContent.
Antes de ver cómo se usan, primero recordemos qué son los simulacros y por qué es posible que desee usarlos.
¿Qué es un simulacro?
En el mundo de JavaScript, el término simulacro se usa mucho para referirse a cualquier implementación simulada o doble de prueba . Las implementaciones simuladas son simplemente valores que reemplazan a otros en su código de producción mientras se ejecutan las pruebas. Intentan en la interfaz del objeto que se reemplaza, por lo que el resto de su código funciona como si no hubiera un reemplazo.
Hay varias razones diferentes por las que podría querer hacer esto; los veremos con ejemplos.
Si está interesado en obtener más información sobre las implementaciones simuladas, lea el libro de Martin Fowler Las simulaciones no son stubs .
Broma y burla
Jest tiene una función
jest.mockque te permite simular módulos completos que reemplazas. En este tutorial, me concentré en esta característica, aunque hay otras formas de reemplazar objetos en JavaScript.
En el libro Mastering React Test-Driven Development, utilizo importaciones de módulos con nombre ES6 para crear dobles de prueba. Este enfoque brinda un poco más de flexibilidad, pero parece un poco más hack.
Jest jest.mockdice que las simulaciones garantizan que sus pruebas sean rápidas y no frágiles .
Si bien esto es cierto, esta no es la razón principal por la que utilizo simulacros.
Utilizo simulacros porque me ayudan a mantener mis pruebas independientes entre sí.
Para entender por qué este es el caso, veamos un ejemplo.
¿Por qué moki?
A continuación se muestra una lista de un componente
BlogPageque hace dos cosas: obtiene idde una propiedad urly luego muestra un PostContentcomponente con eso id.
const getPostIdFromUrl = url =>
url.substr(url.lastIndexOf("/") + 1)
export const BlogPage = ({ url }) => {
const id = getPostIdFromUrl(url)
return (
<PostContent id={id} />
)
}Imagine que está escribiendo pruebas para este componente y que todas sus pruebas están incluidas
BlogPage.test.js, que es un conjunto de pruebas único que cubre componentes BlogPagey PostContent.
En este punto, todavía no necesita los simulacros: aún no los hemos visto
PostContent, pero dado el tamaño BlogPage, realmente no es necesario tener dos conjuntos de pruebas separados, ya BlogPageque generalmente es simple PostContent.
Ahora imagine agregar funcionalidad
BlogPagetanto a y como a y PostContent. Como desarrollador talentoso, agrega más y más funciones todos los días.
Se vuelve más difícil mantener las pruebas en funcionamiento. Cada nueva prueba tiene una configuración más compleja, y el conjunto de pruebas comienza a consumir más tiempo, una carga que ahora necesita soporte.
Este es un problema común y lo veo todo el tiempo en las bases de código de React. Conjuntos de pruebas en los que incluso el cambio más simple provocará que muchas pruebas fallen.
Una solución es dividir los conjuntos de pruebas. Saldremos
BlogPage.test.jsy crearemos PostContent.test.jsuno nuevo que debería contener pruebas exclusivamente para PostContent. La idea básica es que todas las funciones colocadas en PostContentdeben especificarse en PostContent.test.jsy todas las funciones colocadas en BlogPage(como el análisis de URL) deben estar en BlogPage.test.js.
Bueno.
Pero y si renderizando
PostContent tiene efectos secundarios?
export const PostContent = ({ id }) => {
const [ text, setText ] = useState("")
useEffect(() => {
fetchPostContent(id)
}, [id])
const fetchPostContent = async () => {
const result = await fetch(`/post?id=${id}`)
if (result.ok) {
setText(await result.text())
}
}
return <p>{text}</p>
};La suite de pruebas
BlogPage.test.jsdebe conocer los efectos secundarios y estar preparada para manejarlos. Por ejemplo, tendrá que tener una fetchrespuesta preparada .
La dependencia que intentamos evitar al dividir nuestras suites de prueba todavía existe.
La organización de nuestras pruebas ciertamente ha mejorado, pero al final, no sucedió nada que hiciera que nuestras pruebas fueran menos frágiles.
Para esto necesitamos un talón (o simulacro)
PostContent.
Y en la siguiente parte veremos cómo hacer esto.
¿Es realmente necesario?
Por cierto, algunas palabras sobre cómo pasar de las pruebas de un extremo a otro a las pruebas unitarias.
Tener pruebas dobles es un indicador clave de que está escribiendo pruebas unitarias.
Muchos probadores experimentados comienzan nuevos proyectos de inmediato con pruebas unitarias (y simulacros) porque saben que a medida que su código base crece, se encontrarán con problemas de inestabilidad de prueba.
Las pruebas unitarias suelen ser mucho más pequeñas que las pruebas de un extremo a otro. Pueden ser tan pequeños que a menudo no requieren más de tres o cuatro líneas de código. Esto los convierte en excelentes candidatos para las prácticas de codificación social, como el emparejamiento y la programación de conjuntos.
Incluso cuando hacemos pruebas unitarias, las pruebas dobles no siempre son necesarias; son solo otra herramienta en su suite que necesita saber cuándo y cómo aplicar.
En la siguiente parte, cubriremos las técnicas básicas de burla .
