6 Phasen beim Refactoring eines Jest-Testfalls
4. September 2019
0 Min. LesezeitEine oft unterschätzte Funktion von Jest ist, festzulegen, wie Assertion-Fehler behandelt werden, die die Konsole bei fehlgeschlagenen Tests ausgibt. Stellen Sie sich den folgenden Testcode vor, der ein Objekt programmgesteuert durchlaufen muss, um sicherzustellen, dass die erwarteten Schlüssel vorhanden sind (mithilfe der Funktion expect):
Der Test ist korrekt geschrieben. Stellen Sie sich nun vor, ein Entwickler im Team nimmt Änderungen am Code vor: Er fügt an einer Stelle eine neue Datei hinzu und vergisst, sie an einer anderen wichtigen Stelle desselben Projekts einzubinden, etwa dafür zu sorgen, dass sie korrekt exportiert wird.
Beim nächsten Testlauf schlägt der Test fehl. Der Grund ist jedoch für die meisten nicht offensichtlich. Und wenn Sie den Code noch nicht kennen, wissen Sie wahrscheinlich nicht einmal, was kaputtgegangen ist. Probieren Sie es aus:
Aus diesem Grund verlangt Jest außerdem die Verwendung von toHaveProperty() mit expect. Das sieht so aus:
Wenn ein Test jetzt fehlschlägt, ist zumindest klarer, welche Eigenschaft fehlt. Wie Sie im nächsten Screenshot sehen, ist die Meldung aber immer noch etwas kryptisch. Was können wir tun? ?
An diesem Punkt reichen die bereits vorhandenen Anmerkungen vielleicht aus. Der Testname erklärt sich von selbst, wie Sie sehen. Allerdings schlägt nur ein Testfall fehl, und anhand eines Test-Traces lässt sich nicht eindeutig erkennen, welche Validatoren verwendet wurden.
Refaktorieren wir den Code:
Wenn mein Test jetzt besteht oder fehlschlägt, ist viel offensichtlicher und intuitiver, was genau getestet wurde, was genau fehlgeschlagen ist und warum:
Viel besser! ???
Wenn Sie Jest genauso lieben wie ich (?) , interessieren Sie vielleicht auch einige meiner anderen Beiträge zu Jest:
Wenn Sie sich auch für Web-Sicherheit interessieren, würde ich mich freuen, Sie in der Slack-Community von The Secure Developer oder auf Twitter zu treffen, falls Ihnen das lieber ist.