Wir möchten Ihre Aufmerksamkeit auf eine weitere Neuheit lenken, die in unserer Vorbestellung enthalten ist - ein Buch über Unit-Tests .
Der Autor der heutigen Veröffentlichung spricht am Beispiel des Front-End kurz und deutlich über die Vorteile von Unit-Tests und TDD.
Viel Spaß beim Lesen!
Unit-Tests sind einer der wichtigsten Ansätze, die jeder Entwickler verfolgen sollte. Ich habe jedoch viele Projekte gesehen, bei denen es schwierig sein kann, Unit-Tests in die Praxis umzusetzen. Dafür gibt es eine Reihe von Gründen. Zum Beispiel könnte jemand sagen, dass Sie sich auf die Entwicklung von Funktionen konzentrieren müssen, und das Schreiben von Komponententests ist in diesem Fall eine ernsthafte zusätzliche Belastung. Andere werden feststellen, dass das Testen ihres Codes nicht trivial ist, da der Code selbst komplex ist. In beiden Fällen wird der Punkt verfehlt.
Ich erinnere mich an diesen Ausdruck: Wenn Sie darüber nachdenken, ob Sie Zeit haben, Komponententests zu schreiben, denken Sie darüber nach, ob Sie aufgrund von Fehlern und Problemen, die darin auftreten, zusätzliche Zeit haben, denselben Code zweimal zu verarbeiten.
Testbaren Code schreiben
Definieren wir zunächst, welche häufigen Fehler das Testen Ihres Codes erschweren. Wenn es um Front-End-Tests geht, ist eines der schwierigsten Probleme, die ich kenne, das Testen von Benutzeroberflächenkomponenten. Das Hauptproblem, auf das ich in diesem Fall gestoßen bin, ist das folgende: Es kommt vor, dass Komponenten zu "intelligent" sind und Abhängigkeiten von anderen Codefragmenten aufweisen, z. B. von API-Aufrufen, Datenladen, Ereignisbehandlung und Implementierung von Geschäftslogik. Viele Entwickler schreiben keine Tests für solche "schweren" Komponenten.
Die einfachste Lösung für dieses Problem besteht darin, die Komponenten in Logik und Präsentation zu unterteilen. Mit dieser Trennung können Sie testen, wie die Präsentationskomponenten der Präsentationslogik entsprechen, die Ereignisverarbeitung und das Rendern durchführen und sich separat auf das Testen der Geschäftslogik in den für die Logik verantwortlichen Komponenten konzentrieren.
Die Sicherstellung, dass Ihre Komponenten testbar sind, ist auch eine gute Möglichkeit, um sicherzustellen, dass sie unabhängig, wiederverwendbar und bequem zusammen zu verwenden sind. Dies ist unbedingt erforderlich, insbesondere wenn Komponenten mit gängigen Tools und Plattformen wie Bit ( Github) projektübergreifend gemeinsam genutzt werden). In der Regel zeigt und testet Bit jede Ihrer Komponenten separat und sendet sie erst dann an eine gemeinsam genutzte Sammlung, um sicherzustellen, dass sie tatsächlich wiederverwendbar sind. Andernfalls ist es sinnvoll, sie trennbar zu machen.
Beispiel: Erkunden wiederverwendbarer Reaktionskomponenten, die auf Bit.dev freigegeben sind
Ein Teufelskreis: Was passiert, wenn Sie keine Komponententests schreiben?
Aus meiner Erfahrung mit Teams, die Unit-Tests nicht richtig anwenden (dh Testabdeckung nicht als Metrik verwenden), haben Unit-Tests entweder zu spät oder von Anfang an begonnen, aber nicht gelernt, wie man sie übt. Es mag viele Gründe dafür geben, aber ich werde einige Beispiele nennen, um Ihnen die Entscheidung zu erleichtern, welches Ihrem Fall am ähnlichsten ist.
Wie wir unseren Code während der Entwicklung testen
Meiner Meinung nach kann die Funktionalität entwickelt werden, sofern Sie sich nicht an die testgetriebene Entwicklung (TDD) halten, vorausgesetzt, das Frontend wird ständig in den Browser geladen. Sie müssen sich auf die Visualisierung der Funktionen und Interaktionen konzentrieren, die in der Benutzeroberfläche stattfinden, da dies die Essenz der clientseitigen Entwicklung ist.
Erst danach, wenn alle Funktionen bereits funktionieren, verlagert sich der Schwerpunkt auf Unit-Tests.
Hier ist das Hauptproblem, mit dem Sie konfrontiert werden müssen: Das Schreiben von Komponententests ist eine zusätzliche Arbeit, die nach Abschluss der Entwicklung der Funktionalität ausgeführt wird. Dieser Ansatz erweckt den Eindruck, dass Unit-Tests eine zusätzliche Aufgabe sind, die zusätzlich zur Entwicklung vorgefertigter Funktionen durchgeführt wird.
Aufgrund dieser Formulierung der Frage klassifizieren sowohl Produktbesitzer als auch Entwickler Unit-Tests als Kosten.
Wenn Sie sich jedoch an TDD halten, entwickelt sich genau das Gegenteil. Da Testfälle im Voraus geschrieben werden, müssen wir nicht alles überprüfen, indem wir die Änderungen ständig visualisieren, da wir den Code während der Entwicklung auf andere Weise überprüfen können. In diesem Fall besteht das Hauptüberprüfungstool darin, Code zu schreiben, der den Komponententestfall besteht.
Daher glaube ich, dass die Praxis von TDD die wichtigste Phase vor der Praxis von Unit-Tests ist.
Wie oft werden Unit-Tests durchgeführt?
Sie fragen sich möglicherweise, wie sich das Ausführen eines Komponententests auf das Schreiben von Komponententests auswirkt. Angenommen, Sie haben einen vollständigen Satz von Tests. Sie verbannen es von Zeit zu Zeit. Daher werden Entwickler selten von seiner Nützlichkeit überzeugt. Darüber hinaus ist es zu spät, selbst wenn der Test fehlschlägt.
Daher ist es wichtig, Unit-Tests mindestens in jeder Phase des Pull-Request-Builds durchzuführen. Indem wir uns an diese Vorgehensweise von DevOps halten, stellen wir sicher, dass jeder neue Codeblock, den wir hinzufügen, eine Reihe von Komponententests besteht. Selbst wenn ein bestimmter Fall geändert werden muss, wird der Entwickler dies tun, bevor der Code zusammengeführt wird.
Wie oft wird die Codeabdeckung durch Tests gemessen?
Wie bei der Testausführung ist diese Messung sowohl psychologisch als auch als Praxis für Entwickler wichtig, um zu beurteilen, ob sie genügend Testfälle vorbereiten, um den gesamten geschriebenen Code abzudecken.
In diesem Fall reicht meines Erachtens das Dashboard allein nicht aus, um die Abdeckung von Komponententests anzuzeigen. Wenn es jedoch möglich wäre, beim Hinzufügen eines neuen Codes einen Messvorgang hinzuzufügen und damit den Grad der Testabdeckung zu überprüfen, wäre eine solche Alternative bequemer, um sofortiges Feedback zu erhalten. Wir könnten sogar Regeln formulieren, nach denen jeder neue Code, der der Datenbank hinzugefügt wird, durch Tests abgedeckt werden muss, beispielsweise 80%. Es ist am besten geeignet, diese Validierung zum Erstellungsprozess der Pull-Anforderung hinzuzufügen.
Da Entwickler sofortiges Feedback zur Unit-Test-Abdeckung ihres Codes erhalten, können sie bei Bedarf Maßnahmen ergreifen, um diese Abdeckung nachzuholen.
Raus aus diesem Kreis
Wenn Sie bereits in diesen Teufelskreis verwickelt sind, können Sie am besten aus diesem Kreis ausbrechen, indem Sie die oben beschriebenen Praktiken verstärken. Da es bei den oben genannten Tests um häufige Tests zur Validierung neu hinzugefügten Codes sowie um das Testen der Abdeckung neuen Codes ging, können Sie ein Verfahren entwickeln, das für jede Operation zum Hinzufügen oder Ändern von Code geeignet ist.
Es ist äußerst unwahrscheinlich, dass Sie genügend Zeit haben, um den gesamten alten Code sofort mit Tests zu behandeln (es sei denn, das Projekt selbst ist vollständig neu), bevor Sie neuen Code schreiben müssen. Verlassen Sie sich daher überhaupt nicht darauf, da dies aus geschäftlicher Sicht unpraktisch ist.In der Zwischenzeit können Sie regelmäßige Messungen durchführen und bestimmte Teile des alten Codes strategisch mit Tests abdecken. Am wichtigsten ist, dass Sie alle Entwickler darin schulen, diese Vorgehensweise zu befolgen. Ebenso wichtig ist es, sich nicht daran zu gewöhnen, diese Arbeit als Kosten zu betrachten und allen Projektbesitzern zu vermitteln, wie wichtig es ist, Komponententests zu schreiben. Andernfalls denken viele Leute, insbesondere Nicht-Techniker, dass Unit-Tests unnötige Arbeit sind, stattdessen könnte man Zeit damit verbringen, neue Funktionen zu entwickeln.
Was ist der wahre Wert all dieser Arbeit?
Unit-Tests sind in vielerlei Hinsicht nützlich. Bei korrekter Anwendung tragen sie dazu bei, die Anzahl der Fehler im Code zu verringern, beim Testen vorhandener Funktionen als Versicherung zu fungieren, beim Umgestalten des Codes nicht beschädigt zu werden und die Gesamtproduktivität auf einem hohen Niveau zu halten.
Wenn man sich den Code ansieht, der durch Unit-Tests gut abgedeckt ist, kann jeder sehen, wie sicher er aussieht.Lassen Sie uns also die Lücken füllen und wieder auf Kurs kommen, indem wir DevOps-Praktiken anwenden und uns daran gewöhnen, gute Komponententests zu schreiben, während wir uns gleichzeitig an die testgetriebene Entwicklung halten.