Dieser Artikel ist keine theoretische Anleitung zum Schreiben von Tests und keine Anleitung zur Verwendung von Werkzeugen in einem bestimmten Stapel, sondern eine Reihe beliebter Fragen, manchmal sogar viele, die nicht gebildet wurden, auf die ich versuchen werde, Antworten zu geben. Die Quelle dieser Fragen sind Kollegen, Personen von beiden Seiten in den Interviews und Bekannten, und die Antworten werden subjektiv, kurz und nicht erschöpfend sein, basierend auf den Materialien anderer Personen und ihren Erfahrungen. Die Zielgruppe des Artikels sind Entwickler, die mit gewissem Erfolg schreiben oder zumindest versuchen, Tests zu schreiben, aber gewisse Schwierigkeiten beim Schreiben haben.
Ich habe versucht, nicht an eine bestimmte Sprache gebunden zu sein, um die Reichweite der Leser zu erhöhen, aber ich werde sofort reservieren, dass ich mit PHPUnit im PHP-Ökosystem arbeite, und daher sind einige meiner Schlussfolgerungen möglicherweise nicht für andere Ökosysteme geeignet. Bei der Auswahl der Fragen und beim Schreiben habe ich mich auf viele Berichte und Artikel konzentriert und diese als Referenz verwendet.
Der Grund für das Schreiben war der kürzlich erschienene Artikel „ PHPUnit. Wretting the Doctrine Entity Manager “per Schleppnetz , von denen einige auch besprochen werden .
Liste der Fragen:
- Tests schreiben oder nicht schreiben?
- Und wenn keine Zeit für Tests vorgesehen ist?
- Arten von Tests, wie wählen?
- Warum fällt es mir schwer, lange Zeit Tests zu schreiben?
- Wie teste ich private Methoden?
- Wie schreibe ich Integrationstests? Wie teste ich die Basis?
- Wie geht's: Integration oder funktional?
- Was tun mit externen Abhängigkeiten?
- Wie vereinfacht sich die Navigation zwischen Test und Testperson?
- Soll ich TDD verwenden?
- Was kann noch verwendet werden, um den Code zu verbessern?
Tests schreiben oder nicht schreiben?
Ich habe viele Meinungen zu diesem Thema gesehen, bin aber zu meiner eigenen gekommen: Ich muss mich auf die Bedürfnisse des Unternehmens konzentrieren.
Für einen Code, der in ein paar Stunden am Knie erstellt wurde, sind keine Tests erforderlich. Andererseits sind für ein großes Unternehmensprojekt mit Hunderten von Arbeitskräften alle gängigen Testarten erforderlich. Und alles, was sich zwischen diesen Polen befindet, sollte als Sonderfall betrachtet werden, um die Kosten bestimmter Testarten zu bewerten: Bei Tests sollte es geringer sein als ohne sie. Persönlich schreibe ich Rauchprüfungen sogar für ein kleines CRUD-Projekt, das einige Wochen dauert, weil sie bereits in einer solchen Entfernung Vorteile bringen und die Entwicklungskosten senken.
Vorteile des Testens, kurz und abstrakt:
- Eine signifikante Reduzierung der Kosten für die Behebung eines Fehlers aufgrund der Früherkennung.
- Verträge fixieren.
- Low-Level-Dokumentation.
- Erkennung von Architekturproblemen.
Wenn es sich bei Ihren Projekten also nicht um einmalige Skripte aus mehreren Dateien handelt, empfehle ich auf jeden Fall, Tests zu schreiben. Daher sollte die Frage aus dem Titel neu formuliert werden: "Inwieweit sollten Tests geschrieben werden und welche?" Darüber weiter.
Und wenn keine Zeit für Tests vorgesehen ist?
Dies ist ein sehr kontroverses Thema, daher werde ich noch einmal einen Vorbehalt machen, dass ich ausschließlich über meine subjektive Meinung spreche, während ich versuche, dies so vorsichtig wie möglich zu tun.
Das Schreiben von Tests ist genauso eine Aufgabe wie das Durchdenken, Codieren oder Debuggen. Tests sind der gleiche Code wie Geschäftslogik oder Controller. Aber haben Sie Fragen dazu? Sie legen keine separate Aufgabe zum Schreiben eines Controllers fest und koordinieren diese nicht mit Managern?
Es ist nicht erforderlich, zusätzliche Zeit für das Schreiben von Unit- und Integrationstests aufzuwenden. Tests werden als Teil der Hauptaufgabe geschrieben. Der technische Leiter des Projekts entscheidet als Eigentümer des Projekt-Repositorys und als kompetente Person, wie, was und mit welcher Art von Abdeckung Tests geschrieben werden sollen, wobei er sich auf die Aufgaben des Unternehmens konzentriert, nicht aufbläst, sondern die Entwicklungskosten senkt.
Es kann jedoch vorkommen, dass der Kunde nicht an Tests glaubt und glaubt, dass Sie mit seiner Hilfe nicht sparen, sondern nur Zeit verschwenden. Er zahlt Geld und legt Bedingungen fest. Mit demselben Erfolg kann er Ihnen verbieten, ein dunkles Thema in Ihrer IDE zu verwenden oder fünf Leerzeichen als Einzug zu verwenden. Und wenn die Bedingungen nicht besprochen werden oder sich die Diskussion in einer Sackgasse befindet, können Sie diese Bedingungen akzeptieren oder ablehnen. Mit beratenden Konsequenzen.
Ich werde einen Vorbehalt machen, dass Letzteres nur dann zutrifft, wenn Sie Tests schreiben, deren Kosten und die geschätzte Amortisation angemessen einschätzen können. Wenn Sie lernen möchten, wie man sie auf Kosten des Arbeitgebers für ein kurzfristiges Projekt schreibt, und er dagegen ist, dann bin ich auf seiner Seite.
Arten von Tests, wie wählen?
Sie können sich die Testpyramide von Mike Cohen ansehen: Als Entwickler interessieren wir uns für die beiden niedrigsten Teststufen. Der maximale Aufwand sollte für Unit-Tests aufgewendet werden. Er ist der billigste (mit billig meine ich die Zeit, die für Entwicklung und Support aufgewendet wird). Solche Tests sind sehr einfach zu implementieren, sehr einfach auszuführen und funktionieren schnell.
Aber ist Unit Testing immer anwendbar oder ratsam? Ich glaube, dass solche Tests für primitive CRUD mit wenig Einfluss zu viel Zeit in Anspruch nehmen und nichts garantieren. Versuchen Sie, das Repository (Repository in DataMapper) zu testen, und beantworten Sie dann die Frage, was es uns gegeben hat. Für eine Vielzahl von Taschenrechnern ist dieser Ansatz jedoch ideal.
Versuchen Sie immer, wenn möglich Unit-Tests zu schreiben, aber testen Sie nicht, was zum Testen nutzlos ist.
Wie kann man die gemeinsame Arbeit von Backend und Frontend testen, wenn es sich um unterschiedliche Projekte auf unterschiedlichen Stacks handelt? Genau wie das Backend und die mobile Anwendung: Dies sind Systemtests, die für QS- und DevOps-Ingenieure und nicht für Entwickler von Interesse sein sollten (nur dann, wenn Sie kein wirklich gnadenloses Scrum haben, bei dem die einzige verfügbare Rolle ein Full-Stack-Entwickler ist).
Darüber hinaus sind Systemtests in Bezug auf Entwicklung und Support sowohl zeitlich als auch in Bezug auf die Infrastruktur am teuersten. Die Lösung der damit verbundenen Probleme liegt bereits außerhalb der Kompetenz von „linearen“ Entwicklern, und die Frage der Anwendung und des Umfangs sollte vom technischen Direktor und den Leitern der Bereiche zusammen mit dem Unternehmen entschieden werden.
Warum fällt es mir schwer, lange Zeit Tests zu schreiben?
Manchmal ist es schwierig, Tests zu schreiben, da der Code nicht für sie bereit ist. Ein Haufen Mobs, von denen einige andere geben, ist ebenfalls eine Folge.
Verwenden Sie keine Register, Singletones oder Locators, da dies Ihr Leben erheblich erschwert. Dies war der Hauptanspruch auf den Artikel, auf den ich oben Bezug genommen habe. Verwenden Sie DI und implementieren Sie die erforderlichen Repositorys sofort in den Diensten. Beachten Sie das Gesetz von Demeter, um Ketten von Mokas zu vermeiden. Versuchen Sie ein wenig Arbeit mit der TDD-Methode.
Behandeln Sie die Tests wie erstklassigen Code und beachten Sie dabei denselben hochwertigen Code wie in der Geschäftslogik. Eine schlechte Testcodequalität verringert die Produktivität im Laufe der Zeit.
Wie teste ich private Methoden?
Auf keinen Fall. Wir testen einen Vertrag - die Schnittstelle, die das Modul zu anderen Modulen bereitstellt. Wir müssen die interne Implementierung nicht testen, sie kann sich ändern.
Was ist, wenn der Test eine komplizierte Logik enthält und das Testen des Vertrags zu einer großen Menge an Eingaben führt, bei denen im Inneren etwas Seltsames passiert? Es ist notwendig, den Code umzugestalten und in verschiedene Klassen zu verteilen, in denen solche privaten Methoden öffentlich werden. Sie schreiben bereits Komponententests. Und wenn es keine Tests gäbe, wären solche Orte schwer zu erkennen, was die Kosten für die Unterstützung eines solchen Codes erhöhen würde.
Wie schreibe ich Integrationstests? Wie teste ich die Basis?
Verwenden Sie Vorrichtungen. Entdecken Sie beliebte Tools auf Ihrem Stack.
Schreiben Sie keine großen Universalpackungen mit Geräten, verwenden Sie deren Mindestanzahl. Wenn Sie für Ihre Tests einen bestimmten Status von Objekten benötigen, verwenden Sie solche Geräte nicht an anderen Orten, an denen ein solcher Status nicht erforderlich ist. Andernfalls wird die Testunterstützung komplizierter: Wenn Sie sie für einige Tests ändern, werden andere beschädigt und es dauert länger.
Es gibt Integrationstests, die keinen vollständigen Zyklus von der Anforderung bis zur Antwort durchlaufen, und die Interaktion von Klassen wird nur innerhalb der Komponente überprüft. Wenn sie nicht direkt mit der Datenbank arbeiten, können Sie eine Reihe von Daten und / oder Moks erstellen, die in die Eingabe eingehen. In solchen Fällen können Sie die Verwendung von Fixtures vermeiden und die Komplexität und Ausführungszeit solcher Integrationstests auf die modulare Ebene reduzieren.
Wie geht's: Integration oder funktional?
Integrationstests sind eine der Teststufen in Bezug auf die Isolation. Funktionsprüfung - Konformitätsprüfung. Diese Definitionen liegen auf verschiedenen Ebenen, und Sie können kein Gleichheitszeichen zwischen sie setzen, aber in der Praxis bedeuten sie in Gesprächen zwischen Entwicklern dasselbe, obwohl dies nicht korrekt ist.
Was tun mit externen Abhängigkeiten?
Wir ersetzen externe Abhängigkeiten durch Moki. Nicht nur für Unit-Tests, sondern auch für Integrationstests.
Beispielsweise verwenden wir den HTTPS-Client, um über die Guzzle-Klasse auf eine API zuzugreifen. Wenn Sie eine Instanz einer solchen Klasse innerhalb der getesteten Klasse erstellen, ist es schwierig, sie zu ersetzen, aber die Lösung ist sehr einfach: Wir implementieren einen solchen Client im Konstruktor und ersetzen ihn während des Testens durch einen Moch.
Wie vereinfacht sich die Navigation zwischen Test und Testperson?
Moderne Entwicklungstools können den Ort von Tests oder Testklassen verfolgen, wenn Sie Namensstandards verwenden. Zur Vereinfachung der Navigation können Sie in JetBrains-Produkten die Tastenkombination Strg + Umschalt + T verwenden. Wenn der Test nicht vorhanden ist, werden Sie aufgefordert, ihn zu erstellen und ein Drahtmodell zu erstellen.
Manchmal benötigen Sie mehrere verschiedene Testklassen oder -methoden für das Testobjekt. In diesem Fall müssen Sie der IDE helfen, z. B. die Annotation @covers im Fall von PHPUnit hinzuzufügen.
Soll ich TDD verwenden?
TDD ist eine der Entwicklungsmethoden, bei denen iterativ und notwendigerweise zuerst Tests und dann Code geschrieben werden. Das Ausprobieren lohnt sich auf jeden Fall. Es zeigt Ihnen, wie Sie gut getesteten Code schreiben. Dieser Ansatz war jedoch nicht weit verbreitet, er hat Probleme. Eines dieser Probleme ist, dass Sie Tests schreiben, die Sie mit dem klassischen Ansatz nicht schreiben würden. Und solche Tests müssen auch unterstützt werden, Zeit dafür aufwenden, und der Nutzen daraus ist gering. Zum Beispiel Tests für Setter oder Tests für Klassen, bei denen außer Abhängigkeitsaufrufen nichts passiert. Solche Stellen werden am besten durch Integrationstests überprüft.
Was kann noch verwendet werden, um den Code zu verbessern?
Statische Analysetools sind eine weitere Möglichkeit, die Qualität Ihres Codes zu verbessern. Sie überschneiden sich teilweise mit den Tests durch das Ergebnis, stellen jedoch häufig fest, dass die Tests nicht gefunden wurden, insbesondere bei schlechter Abdeckung. Ihr zweifelsfreier Vorteil: Sie sehen das Ergebnis sofort in der IDE und erhalten sofort Feedback.
Dies bedeutet nicht, dass es ausreicht, sie nur in der IDE zu belassen. Ich empfehle dringend, sie im CI zu verwenden, um mögliche Fehler zu erkennen und solchen Code nicht zu verderben.
Ich empfehle außerdem, der IDE und dem CI Unterstützung für Tools zur Überprüfung des Codestils hinzuzufügen. Fehler werden häufig in unachtsam geschriebenem Code versteckt, und mit solchen Tools können Sie solche Bereiche finden.
Materialien für weitere Studien