Im Leben eines jeden Entwicklers kommt ein Moment, in dem er darüber nachdenkt, eine Testkomponente für seine Idee zu erstellen. Ich werde mich erholen - im Leben eines jeden guten Entwicklers. Wenn Sie ein Junior sind und keine besondere Verantwortung tragen, haben Sie das Recht auf viele Fehler und können diese jederzeit korrigieren. Sie sind nicht für das von Ihnen erstellte Produkt verantwortlich und haben nicht die Motivation, eine zusätzliche Minute für die Überprüfung des generierten Codes aufzuwenden. "Nichts, dieser Pfosten kann nicht reproduziert werden", "dieses Ding scheint zu funktionieren", "nun, zumindest tut es, was benötigt wird" - wenn Sie über das Niveau des Programmierkindergartens hinauswachsen möchten, müssen Sie jeden dieser Gedanken negieren.
Mit der Entwicklung Ihrer eigenen Programmiererfahrung haben Sie immer mehr coole / große Kunden. Sie werden sogar von einigen begeistert sein (von allem, wenn Sie Glück haben) - die Leute sind gut und zahlen großzügig und sind nicht wählerisch in Bezug auf die auftretenden Probleme. Schauen wir uns einen so einfachen Fall an (sehr einfach, aber die Hauptsache, der dahinter steckt), einen Formularhandler von einem Programmierer zu erstellen, der den Aufwand nicht kennt.
Die einfache Aufgabe ist also gekommen - einen Formularhandler zu schreiben. Ziel ist es, Anträge von Kunden auf Kauf von Ziegeln anzunehmen. Der Kunde ist groß, er ist mit großen Lieferungen von Ziegeln in loser Schüttung beschäftigt (zum Beispiel für eine Menge von mehr als 500.000 Rubel - um zumindest ein gewisses Maß an Verantwortung für das zu fühlen, was passiert). Der Wettbewerb ist hart - Kunden können schnell zum Ziegellieferanten gehen, wenn sie nicht innerhalb eines Tages antworten.
Unserem Programmierer wurde mitgeteilt, dass Kundendaten aus dem Formular gespeichert werden müssen - Name des Vertreters, Telefonnummer, Name des Unternehmens des Kunden, Auftragsvolumen und ein optionales Feld für die Auftragsbeschreibung. Porakinin Gehirn, eine einfache Form wurde schnell mit Standardfeldern für die Vorderseite der Website erstellt:
Daten aus dem Formular werden per AJAX-Anfrage gesendet, ohne die Seite neu zu laden. Darüber hinaus übernimmt der Programmierer das Design des Formularhandlers und muss eine eher triviale Aufgabe bewältigen - Einträge für den neuen Kunden zur bereits vorhandenen Auftragstabelle hinzufügen und dem Kunden eine E-Mail mit einer Benachrichtigung über den neuen Kunden senden.
Das Formular funktioniert, die Daten werden erfolgreich gespeichert, der Kunde ist zufrieden. Aber plötzlich kommt ein verärgerter Anruf vom Kunden: „Sie sagen, die Bestellung ist eingetroffen - die Millionärsfirma möchte alle Steine von mir kaufen, aber die Telefonnummer stammt nicht aus dem Formular und wie kann ich sie jetzt kontaktieren?! Morgen finden sie einen anderen Lieferanten! Wie also was hast du gemacht ?! Es ist deine Schuld ... " Der Kunde zerreißt und wirft, minus Nerven, minus Vertrauen und minus Respekt. Die Situation ist für einen Junior äußerst normal - das Fehlen jeglicher Validierung und Prüfung eingehender Daten aus dem Formular. Die erste Aufgabe (Validierung) wird extrem einfach durch Hinzufügen von Validierungsregeln gelöst:
Von nun an gibt der Site-Client nur noch die korrekten Daten an, die wir für die weitere Verarbeitung benötigen. Gleichzeitig hat der Entwickler die Idee, den Code zu testen, um eine solche unangenehme Situation weiter zu vermeiden. Das Testen des Felds für den Nachnamen sieht beispielsweise folgendermaßen aus (um das grundlegende Beispiel zu vereinfachen, ist der CSR-Schutz deaktiviert):
Wir wissen, dass der Code in Abwesenheit dieses Felds eine von uns registrierte Antwort mit einem Fehler und einem Status von 400 zurückgeben sollte. Solche Testmethoden werden für jede spezifische Situation (oder spezifische Feldvalidierung, alles hängt von den Aufgaben und der Vorstellungskraft des Entwicklers ab) vorgeschrieben.
Aber gibt es eine andere Entwicklungsmethode als "Ich habe es getan, aber jetzt werde ich es überprüfen"? Wir schreiben zuerst den Code, stolpern über die Pfosten der Ausführung, reparieren ihn und erinnern uns dann an die Tests. Dieser Ansatz kann für uns und unseren Kunden angesichts des verlorenen millionenschweren Kunden seitwärts gehen (obwohl theoretisch alle diese Kunden dies wären). Und dann habe ich mich gefragt - was ist, wenn wir die Logik zum Erstellen der Anwendung am anderen Ende beginnen -, dass wir zuerst Anforderungen an den „Executor“ stellen und dann diese Anforderungen erfüllen? Lass es uns versuchen.
Wir verlassen die Aufgabe wie zuvor, wir ändern nur die Herangehensweise daran. Wir müssen einen Formularhandler mit den Feldern fio, phone, corp, quant und content schreiben. Das Ergebnis einer erfolgreichen Ausführung ist der Status 200, das Hinzufügen eines Felds zur Bestellung mit der Meldung "OK" und das Zurückgeben von Daten zum eingegebenen Datensatz, anderen Optionen - Status 400 und einer Liste von Fehlern.
Zunächst müssen wir eine Testmethode zum gültigen Ausfüllen von Formulardaten schreiben:
Erstellen Sie als Nächstes die erforderliche Route und Controller-Methode (leer). Wenn wir den Test jetzt ausführen, wird ein Fehler erwartet. Die Validierung gültiger Daten ist nicht alles, was wir brauchen. Jetzt beginnen wir mit dem Testen der Formularfeldvalidierung. Wir bestimmen, welche Felder erforderlich sind - fio, phone, corp, quant und fügen eine Methode zur Überprüfung hinzu (Kommentar ist optional):
Der Formular-Handler muss lediglich nach eingehenden Daten fio, phone, corp, quant suchen. Da wir alle erforderlichen Felder aus der Anforderung entfernt haben, sollte für jedes ein Fehlerfehler zurückgegeben werden. Für den Fall, dass mindestens einer von ihnen nicht vorhanden ist - das Ausführungsproblem. Falls gewünscht, können Sie wie zuvor eine Überprüfung auf Nachricht hinzufügen (auf „OK“ prüfen).
Wir stellen eine Prüfung für die Mindestlänge der Felder fio, phone und corp aus (eine ähnliche Prüfung wird für die maximale Länge und für ungültige Zeichen in diesen Feldern durchgeführt).
Unsere Überprüfungen sind vorhanden, Sie können ausführen und überprüfen
Perfekt. Unsere Anwendung stürzte in 5 von 5 Tests ab. Unser weiteres Ziel ist es, Testmethoden durchzugehen, die ungültige Werte für Felder festlegen und Validierungsregeln für eingehende Daten bilden. Die Logik ist ungefähr so: Das fio-Feld kann nicht leer sein; Länge nicht weniger als 3 und nicht mehr als 120; Dies ist eine Zeichenfolge mit den im Namen zulässigen Zeichen (Buchstaben, Bindestriche, Einrückungen). Das Ergebnis dieser Logik in allen Bereichen:
Als Antwort auf eine Datei wurde eine Liste von Fehlern hinzugefügt, die jedem Feld "Problem" entsprechen. Dies hilft uns, bestimmte Felder auf Validierung zu überprüfen (assertJsonStructure in der Testdatei). Als nächstes fügen wir die Methode zur Validierung hinzu und erhalten die endgültige Version:
Und schließlich können wir überprüfen, wie unser Skript beim Testen funktioniert (ich erinnere mich, es gab 5 Fehler in 5 Tests).
Wie Sie sehen, wurden alle Tests erfolgreich bestanden und nur ein Eintrag wurde in die Datenbank eingegeben (da nur eine Methode für die ordnungsgemäße Funktion konfiguriert wurde).
Was sind die Ergebnisse? Die Anwendungsentwicklung, beginnend mit Tests, ist eine bessere Option als das übliche Schreiben von Funktionen. Die Notwendigkeit, von der Methode nur das zu erhalten, was benötigt wird, ist vergleichbar mit der Disziplin der Armee - der Code macht genau das, was Sie von ihm verlangen, nicht einen Schritt zur Seite. Dieser Ansatz hat jedoch eine negative Seite (wenn auch kontrovers) - Tatsache ist, dass das Schreiben zusätzlicher Funktionen (die getestet werden) auch einen Teil der für die Entwicklung des Projekts vorgesehenen Zeit in Anspruch nimmt. Für mich ist die Wahl klar: Ein guter Programmierer sollte Tests schreiben, und wenn Sie mit der Testfunktionalität beginnen, können Sie ein gut funktionierendes und zuverlässiges Projekt schreiben. Ich werde versuchen, es in etwas weniger Trivialem zu verwenden.