Tengo algunas funciones útiles que estoy usando entre varias pruebas de Jest, por ejemplo, una función como esta, para burlarse de una respuesta de búsqueda:
export const mockFetchJsonResponse = (data) => { ok: () => true, json: () => data };Me gustaría compartir esas funciones de manera que pueda importarlas y reutilizarlas entre mis pruebas. Por ejemplo:
// Some .spec.jsx file // ... import {mockFetchJsonResponse} from 'some/path/to/shared/tests/utils.jsx' // Then I can use mockFetchJsonResponse inside this test // ...¿Dónde debo colocar tales funciones útiles comunes?
La carpeta de mi proyecto se ve así:
components/ CompOne/ __tests__ index.jsx CompTwo/ __tests__ ... utils/ __tests__ http.js user.js ... ¿Debo colocarlos dentro de la carpeta utils junto con otras funciones utils que uso para mi proyecto? Entonces, ¿debería escribir pruebas unitarias también para estas funciones?
Existe la posibilidad de exponer ayudantes como funciones globales sin necesidad de importar módulos explícitamente.
setupFilesglobal que puede modificar y todo lo que coloque allí estará disponible en sus pruebas.paquete.json:
"jest": { "setupFiles": ["helpers.js"] }ayudantes.js:
global.mockFetchJsonResponse = (data) => { ok: () => true, json: () => data };algún componente.prueba.js:
mockFetchJsonResponse(); // look mom, I can call this like say expect()! TypeScript se quejará de cannot find name 'mockFetchJsonResponse' . Puede solucionarlo agregando un archivo de declaración:
ayudantes.d.ts:
declare function mockFetchJsonResponse(data: any): any; Cree un nuevo archivo tsconfig.test.json y agréguelo a la sección de files y amplíe su tsconfig principal:
{ "extends": "./tsconfig.json", "files": ["./.jest/helpers.d.ts"] } En su archivo jest.config.js , agregue una nueva configuración global para ts-jest para que jest use su nuevo archivo tsconfig:
// ... globals: { "ts-jest": { tsconfig: "tsconfig.test.json" } } // ... Claro que no responde a su pregunta directa "dónde colocar los archivos", pero de todos modos depende de usted. Solo necesita especificar esos archivos en la sección setupFiles . Dado que no se necesita import en las pruebas, realmente no importa.
En cuanto a probar los ayudantes de prueba, no estoy seguro. Vea que es parte de la infraestructura de prueba como el propio archivo de especificaciones. Y no escribimos pruebas para pruebas o nunca se detendría. Claro, depende de usted, diga si la lógica detrás es muy, muy compleja y difícil de seguir. Pero si el asistente proporciona una lógica demasiado compleja/complicada, las pruebas en sí serían imposibles de entender, ¿está de acuerdo?
Felicitaciones a ese artículo sobre la prueba de componentes con intl . Nunca he tratado con globals en broma antes.
Otro enfoque es tener un directorio de prueba y mover ayudantes en él.
src/ components/ utils/ ... test/ testHelpers.jsLuego en la prueba:
// src/components/MyComponent.spec.js import { helperFn } from '../../test/testHelpers';Beneficios:
Inconvenientes:
test puede parecer tonto al contener solo un archivo de ayudaParece queGitLab está implementando este enfoque en su proyecto RoR.
¹ independientemente del enfoque que adopte, no pruebe los asistentes de prueba. Si el ayudante falla, su prueba también debe fallar. De lo contrario, su ayudante no está ayudando en absoluto.
TL;RD; cree /__utils__/ y actualice testPathIgnorePatterns
Respuesta completa:
Aquí hay solo una sugerencia:
testPathIgnorePatterns: ['/__fixtures__/', '/__utils__/'], Uso /__tests__/ para las pruebas y, dentro de él, a veces necesito agregar una carpeta con los datos que usarán esas pruebas, así que uso la carpeta /__fixtures__/ .
Del mismo modo, cuando tengo una lógica compartida entre pruebas, las coloco en la carpeta /__utils__/ (también dentro de /__tests__/ )
Para obtener más detalles, lea más sobre testPathIgnorePatterns