Easy Agile Team

Wir alle wissen, dass das Schreiben von Komponententests wichtig ist, aber manchmal fühlt es sich an, als ob es mehr Zeit in Anspruch nehmen kann als die Feature-Arbeit selbst. Ich habe ein paar praktische Hacks gefunden, von denen ich glaube, dass sie meine Geschwindigkeit beim Schreiben von Tests erhöht und gleichzeitig deren Qualität verbessert haben. Da ich der nette Kerl bin, werde ich sie mit Ihnen teilen:

Hack 1: Benutze Testing Playground

Ich denke, der erste Tipp in diesem Artikel ist - benutze Bibliothek zum Testen. Ich habe das nicht zu meinem eigenen Argument gemacht, weil es bereits so beliebt ist. Aber wenn Sie es noch nicht verwenden, stellen Sie sicher, dass Sie es tun!

Unit-Tests mit der Testing Library sind wirklich einfach und intuitiv. Trotzdem kann es immer noch schwierig sein, die richtigen Abfragen zu finden oder zu verstehen, warum ein Element nicht gefunden wird.

Geben Sie ein Playground testen.

Beim Testen von Playground können Sie eine Komponente in einer Sandbox rendern, sodass Sie direktes visuelles Feedback der Komponente erhalten. Außerdem können Sie mit der gerenderten Komponente interagieren, um die besten Abfragen für die Auswahl von Elementen zu erstellen. Und wie bei Testing Library steht bei allem, was es tut, Barrierefreiheit (a11y) im Vordergrund, sodass Sie bei der Verwendung von a11y über die Bedeutung von a11y und über bewährte Methoden informiert werden.

Es gibt viele Möglichkeiten, Testing Playground zu verwenden, einschließlich eines Chrome-Geräts Ausdehnung und ein browserbasierte App.

Der beste Weg, den ich gefunden habe und der für mich eine absolute Zeitersparnis war, ist der Aufruf screen.log testingPlaygroundUrl () direkt aus dem Testblock selbst. Normalerweise mache ich das, sobald ich das Komponenten-Rendering habe, nur um mir einen Überblick zu verschaffen und herauszufinden, mit welchen Teilen mein Test interagieren möchte.

Hack 2: Benutze test.todo

Bitte springen Sie mir nicht an die Gurgel, aber ich habe es versucht Testgetriebene Entwicklung und mochte es nicht. Wie beim Anarchismus finde ich, dass es in der Theorie großartig klingt, aber ich habe festgestellt, dass es meinen Entwicklungszyklus tatsächlich verlangsamt hat, als ich versuchte, ihn umzusetzen.

Mir gefällt jedoch immer noch die Idee, etwas über das Testen nachzudenken, bevor ich mit der Entwicklung eines Features fertig bin und mich für einen Prozess entschieden habe, der für mich gut zu funktionieren scheint und meine Entwicklung vorantreibt.

Ich verwende jetzt test.todo von Jest, um aufzuzeichnen, was ich testen werde, während ich ein Feature plane und ausbaue (Vielen Dank an Karl dafür, dass du mir die Idee zum ersten Mal vorgestellt hast!).

Mein üblicher Prozess läuft ein bisschen so ab. Zuerst erfasse ich die Anforderungen, die mein großartiger Product Owner (Hi Biz!) für mich formuliert hat im test.todo-Format, wie eine Todo-Liste. Wenn ich dann baue und auf andere Randfälle und wichtige Testbereiche stoße, füge ich diese auch als test.todo's hinzu. Auf diese Weise habe ich in Bezug auf die Testzeit vieles durchdacht, was ich testen werde, und es ist weniger wahrscheinlich, dass ich das Testen von Randfällen oder wichtigen funktionalen Anforderungen übersehe.

Ein einfaches Beispiel für ein test.todo für die folgende Komponente: <UserDetails />

importiere React aus „react“; Exportschnittstelle User {firstName: string; lastName: string; username: string; emailAddress: string; SEN: string;} Exportschnittstelle showHideUserDetailsProps {showDetails: boolean; user: user;} const userDetails = ({showDetails, user}: showHideUserDetailsProps) => (<> {showDetails? (<div><h1>Benutzerdetails</h1> <ul><li>{User.FirstName}</li> <li>{User.LastName}</li> <li>{user.username}</li> <li>{user.emailAddress}</li> <li>{user.SEN}</li></ul></div>): (<div><h1>Privacy Protected</h1></div>)} </>); Standard-Benutzerdetails exportieren;

Könnte wie folgt aussehen:

describe ('<UserDetails />', () => {test.todo ('Sollte Benutzerdetails anzeigen, wenn „Details anzeigen“ wahr ist'); test.todo ('Sollte KEINE Benutzerdetails anzeigen, wenn „Details anzeigen“ falsch ist');});

Hack 3: Builder-Funktionen verwenden

Früher habe ich für jeden Test Objekte erstellt, um Werte für das Testen nachzuahmen. Dann habe ich eine weitere Komponente geschrieben, die dasselbe Objekt verwendet hat, und es dort wieder verspottet. Es muss einen besseren Weg geben, dachte ich. Und Matt Smith von FinoComp hat mir einen vorgestellt.

Ich verwende jetzt Builder-Funktionen, die beim Testen häufig verwendete Objekttypen zurückgeben und es ermöglichen, Eigenschaften überall zu überschreiben. Es ist sicherlich ein bisschen mehr Zeit erforderlich, um sie einzurichten, aber ich finde, dass Sie, wenn sie einmal fertig sind, das nächste Mal, wenn Sie mit dem Objekt interagieren müssen, so froh sind, dass sie da sind.

//Beispiel für das Typinterface User {firstName: string; lastName: string; username: string; emailAddress: string; SEN: string;} interface showHideUserDetailsProps {showDetails: boolean; user: user;}//Builder-Muster zum Erstellen eines Scheinobjekts für den//showHideUserDetailsProps Typeexport const buildShowHideUserDetailsProps = (überschreibt? : Teilweise<ShowHideUserDetailsProps>): showHideUserDetailsProps => {const defaultShowHideUserDetailsProps = {showDetails: false, user: {firstname: „Jazmyne“, lastname: „Jacobs“, username: „Kylee_Skiles37", emailAddress:" Rashawn13@gmail.com „, SEN: „SEN-123456"}}; return {... defaultShowHideUserDetailsProps,... überschreibt};};

Dieses Muster weist jedoch einige Einschränkungen auf, da es bei tief verschachtelten Objekttypen weniger nützlich ist. Außerdem müssen sie gewartet werden, wenn sich Objekttypen in der Codebasis ändern, was mich zu meinem nächsten Punkt bringt...

Hack 4: Benutze ein Tool, um deine Typescript-Typen nachzuahmen

Schau, ich werde direkt herkommen. Das ist der Teil, in dem ich meine eigene Arbeit einfüge, aber wenigstens habe ich sie zum Schluss gelassen, oder?

Immer wenn ich ein anderes Scheinobjekt zum Testen erstellte, schaute ich mir meine Typescript-Typen an und dachte, kann sich das nicht etwas ansehen und für mich tun? Das hat mich auf die Suche nach einer Lösung geschickt und ich war so begeistert, sie zu finden Zwischenmatte welches ist ein Befehlszeilentool, das genau das tut. Es ist zwar noch in Arbeit und hat einige Einschränkungen, aber ich fand es sehr hilfreich beim Schreiben von Tests.

Ich fand es allerdings etwas umständlich, die Kombination aus CLI und Kopieren/Einfügen vom Terminal aus zu verwenden. Wie könnte ich das noch einfacher machen, dachte ich.

Gib meine VSCode-Erweiterung ein, Emulativ. Wählen Sie einfach Ihren Typnamen aus, führen Sie einen Befehl über die Befehlspalette in VSCode aus und Sie können Emulative verwenden, um Typescript-Objekte, Json-Objekte oder die oben genannten Builder-Funktionen aus Typescript-Typen zu erstellen. Diese werden automatisch in die Zwischenablage kopiert, aber die einfachen Objekte können auch in eine neue Scratch-Datei gesendet werden.

Aber warte, es gibt noch mehr! Wo ich arbeite Einfach und agil Wir haben eine Reihe von Eigenschaften, mit denen wir von Jira arbeiten, die nicht genau durch eine Zeichenfolge oder Zahl dargestellt werden. Mit Emulative können Sie Schlüssel/Wert-Paare einrichten, die alle passenden Eigenschaften, die in Ihren Typen enthalten sind, überschreiben.

Ein Lob an Easy Agile, dass sie mir während einer Inception Week die Zeit, die Ressourcen und die Ermutigung gegeben haben, an Emulative zu arbeiten!

Nun, das war's für mich. Ich hoffe, Sie finden einige dieser Tipps und Tricks nützlich, um Frontend-Tests zu beschleunigen.

In jedem Fall können Sie sich gerne in den Kommentaren über raffinierte Tricks äußern, die Sie gefunden haben, um Ihre Komponententestgeschwindigkeit zu verbessern (oder einfach, wie falsch ich in Bezug auf TDD liege).