Shared utils-Funktionen zum Testen mit Jest

Ich habe einige utils-Funktionen, die ich bei verschiedenen Jest-Tests verwende, zum Beispiel eine Funktion wie diese, um eine Abrufantwort zu verspotten:

export const mockFetchJsonResponse = (data) => {
    ok: () => true,
    json: () => data
};

Ich möchte diese Funktionen so teilen, dass ich sie importieren und in meinen Tests wiederverwenden kann. Zum Beispiel:

// Some .spec.jsx file
// ...
import {mockFetchJsonResponse} from 'some/path/to/shared/tests/utils.jsx'

// Then I can use mockFetchJsonResponse inside this test
// ...

Wo sollte ich solche allgemeinen utils-Funktionen platzieren?

Mein Projektordner sieht so aus:

components/
    CompOne/
        __tests__
        index.jsx
    CompTwo/
        __tests__
        ...
utils/
    __tests__
    http.js
    user.js
    ...

Soll ich sie in die einbauen utils zusammen mit anderen utils-Funktionen, die ich für mein Projekt verwende? Soll ich dann auch für diese Funktionen Unit-Tests schreiben?

Es besteht die Möglichkeit, Helfer als globale Funktionen bereitzustellen, ohne dass Module explizit importiert werden müssen.

1. Jest ermöglicht die Konfiguration einiger Dateien, die ausgeführt werden, bevor jede Testdatei ausgeführt wird setupFiles Konfigurationsmöglichkeit
2. Auch Jest bietet global Objekt, das Sie ändern können, und alles, was Sie dort ablegen, wird in Ihren Tests verfügbar sein.

Beispiel

Paket.json:

"jest": {
    "setupFiles": ["helpers.js"]
} 

helpers.js:

global.mockFetchJsonResponse = (data) => {
    ok: () => true,
    json: () => data
};

somecomponent.test.js:

mockFetchJsonResponse(); // look mom, I can call this like say expect()!

Mit TypeScript

TypeScript wird sich beschweren cannot find name 'mockFetchJsonResponse'. Sie können das beheben, indem Sie eine Deklarationsdatei hinzufügen:

Helfer.d.ts:

declare function mockFetchJsonResponse(data: any): any;

Erstelle eine neue tsconfig.test.json Datei und fügen Sie diese Datei der files Abschnitt und erweitern Sie Ihre Haupt-tsconfig:

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

In deiner jest.config.js Datei, fügen Sie ein neues globales Setup für hinzu ts-jest um je Ihre neue tsconfig-Datei zu verwenden:

// ...
globals: {
    "ts-jest": {
         tsconfig: "tsconfig.test.json"
    }
}
// ...

Sicher, es beantwortet Ihnen nicht direkt die Frage “wohin mit den Dateien”, aber es liegt trotzdem an Ihnen. Sie müssen diese Dateien nur in angeben setupFiles Sektion. Da es keine gibt import benötigt in Tests spielt es keine Rolle.

Was das Testen von Testhelfern betrifft, bin ich mir nicht sicher. Sehen Sie, es ist Teil der Testinfrastruktur wie die Spezifikationsdatei selbst. Und wir schreiben keine Tests für Tests, sonst würde es nie aufhören. Sicher, es liegt an Ihnen – sagen Sie, ob die Logik dahinter wirklich sehr komplex und schwer zu befolgen ist. Aber wenn der Helfer eine zu komplexe/komplizierte Logik bereitstellt, würde dies dazu führen, dass die Tests selbst unmöglich zu verstehen sind, stimmen Sie zu?

lob dafür Artikel zum Testen von Komponenten mit intl. Noch nie behandelt globals im Scherz vorher.

TL;DR; ein … kreieren /__utils__/ und aktualisieren testPathIgnorePatterns

Vollständige Antwort:

Hier nur ein Vorschlag:

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

ich benutze /__tests__/ für die Tests und darin muss ich manchmal einen Ordner mit Daten hinzufügen, die von diesen Tests verwendet werden, also verwende ich /__fixtures__/ Mappe.

Ebenso platziere ich, wenn ich über Tests hinweg eine gemeinsame Logik habe, sie bei /__utils__/ Ordner (auch innerhalb /__tests__/)

Für weitere Details lesen Sie bitte mehr über testPathIgnorePatterns

Ein anderer Ansatz besteht darin, ein Testverzeichnis zu haben und Helfer darauf zu verschieben.

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

Dann zum Test:

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

Vorteile:

• Geben Sie explizit an, woher die Funktion kommt
• Trennen Sie Helfer, die getestet werden müssen, von denen, die dies nicht tun ¹

Nachteile:

• Das test Verzeichnis könnte albern aussehen, wenn es nur eine Hilfsdatei enthält
• AFAIK dieser Ansatz ist nirgendwo in offiziellen Unterlagen angegeben

Sieht aus wie GitLab implementiert diesen Ansatz bei ihrem RoR-Projekt.

¹ Egal welchen Ansatz Sie wählen, testen Sie die Testhelfer bitte nicht. Wenn der Helfer fehlschlägt, muss auch Ihr Test fehlschlagen. Sonst hilft dein Helfer überhaupt nicht.