Funciones de utilidades compartidas para probar con Jest

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 utils carpeta junto con otras funciones útiles 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.

1. Jest permite configurar algunos archivos que se ejecutarán antes de que cada archivo de prueba se ejecute a través de setupFiles opción de configuración
2. También Jest proporciona global objeto que puedes modificar y todo lo que pongas allí estará disponible en tus pruebas.

Ejemplo

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()!

con mecanografiado

TypeScript se quejará con cannot find name 'mockFetchJsonResponse'. Puede solucionarlo agregando un archivo de declaración:

ayudantes.d.ts:

declare function mockFetchJsonResponse(data: any): any;

Crear un nuevo tsconfig.test.json archivo y agregar ese archivo a la files sección y extienda su tsconfig principal:

{
    "extends": "./tsconfig.json",
    "files": ["./.jest/helpers.d.ts"]
}

En tus jest.config.js archivo, agregue una nueva configuración global para ts-jest para tener broma 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 setupFiles sección. Como no hay import necesario en las pruebas en realidad 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 eso artículo sobre pruebas de componentes con intl. nunca he tratado globals en broma antes.

TL;RD; crear un /__utils__/ y actualizar testPathIgnorePatterns

Respuesta completa:

Aquí hay solo una sugerencia:

testPathIgnorePatterns: ['/__fixtures__/', '/__utils__/'],

yo suelo /__tests__/ para las pruebas y dentro de él a veces necesito agregar una carpeta con datos que serán utilizados por esas pruebas, entonces uso /__fixtures__/ carpeta.

Del mismo modo, cuando tengo una lógica compartida entre pruebas, las coloco en /__utils__/ carpeta (también dentro /__tests__/)

Para obtener más detalles, lea más sobre testPathIgnorePatterns

Otro enfoque es tener un directorio de prueba y mover ayudantes en él.

src/
  components/
  utils/
  ...
test/
  testHelpers.js

Luego en la prueba:

// src/components/MyComponent.spec.js
import { helperFn } from '../../test/testHelpers';

Beneficios:

• Sea explícito de dónde viene la función
• Separe a los ayudantes que necesitan ser evaluados de aquellos que no ¹

Inconvenientes:

• los test El directorio puede parecer tonto al contener solo un archivo de ayuda
• AFAIK, este enfoque no se especifica en la documentación oficial

Parece GitLab 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.