In dem Projekt, zu dem ich gehöre, entwickle ich Tests für jede Klassenmethode (es ist schwer zu sagen, dass es sich um einen Komponententest handelt ...) und Tests für jede API. Der Test verwendet Pytest. Da wir mit mehreren Mitgliedern entwickeln, führt Jenkins den Test automatisch aus, bevor er bereitgestellt wird, wenn er zusammengeführt und in das Repository verschoben wird, und wird bereitgestellt, wenn er erfolgreich ist. Hier ist eine Zusammenfassung dessen, was gut und schmerzhaft ist (obwohl es noch in Arbeit ist) und was meiner Meinung nach verbessert werden sollte. (Im Folgenden nur Text!)
--Sie können sicher sein
Ich bin erleichtert, wenn der Test bestanden ist. Beruhige dich mental. Dies ist wichtig für die Klangentwicklung.
Sie müssen nicht arbeiten, während Sie sich immer Gedanken machen über "Ist der Code, den ich geschrieben habe, in Ordnung?"
Wenn nach dem Start des Dienstes ein schwerwiegender Fehler auftritt, muss dieser schnell und genau behoben werden, und er verliert natürlich seinen Ruf.
Darüber hinaus müssen wir uns auf den nächsten Dienst vorbereiten, während wir uns damit befassen.
Ich möchte eine solche Situation so weit wie möglich vermeiden.
Wenn Sie einen Test schreiben und ihn jedes Mal automatisch ausführen, wenn Ihr Code zusammengeführt wird, können Sie den Fehler schnell finden und beheben, wenn Sie es sich leisten können.
Wenn ein Fehler auftritt, stellen Sie möglicherweise eine Diskrepanz in den Spezifikationen fest, während Sie nach der Ursache suchen.
Wenn dies auch nach der Veröffentlichung entdeckt wird, ist es schwierig.
Es ist sehr hilfreich, es frühzeitig erkennen zu können.
Dies gilt auch für Stammdaten.
Wenn Daten erstellt werden, die der Techniker nicht erwartet hat, können Sie überprüfen, was die Absicht für diese Daten war, und Maßnahmen ergreifen.
Wenn Sie Korrekturen vornehmen, können Sie den von den Mitgliedern geschriebenen Code lesen.
Die Codeüberprüfung wird separat durchgeführt. Danach haben Sie die Möglichkeit, den Code zu lesen, um Wissen zu erlangen und Probleme zu entdecken.
Die Testausführungszeit wird immer länger. Insbesondere das Testen von Methode zu Methode kann sehr lang sein.
Derzeit dauert es ungefähr eine Stunde, um alles auszuführen (obwohl das Testen der API einige Minuten dauert).
Das ist richtig, aber es ist auch ein Problem.
Derzeit führe ich den Test des korrigierten Teils in meiner Umgebung aus, und wenn der Test erfolgreich ist, lassen Sie Jenkins alles tun.
Es gibt zwei Hauptursachen für Fehler in Ihrem Projekt.
Einer ist ein Fehler, der durch die Aktualisierung der Stammdaten verursacht wird. Der andere ist ein Fehler aufgrund einer Spezifikationsänderung.
Letzteres kommt gelegentlich vor, Ersteres jedoch häufig und ist ehrlich gesagt schwierig zu handhaben.
Dies liegt daran, dass die Tests, die wir schreiben, eng mit den Stammdaten verknüpft sind.
Um ein einfaches Beispiel zu geben, schreibe ich einen Test, dass Sie 100 Yen erhalten, wenn Sie einen Artikel mit der ID 1 verkaufen. Aus diesem Grund schreiben wir keinen "Unit Test", sondern einen klassenbasierten Test.
Stammdaten ändern sich häufig während der Entwicklung.
Der Verkaufspreis ändert sich oder die ID-Daten selbst verschwinden.
Überprüfen Sie jedes Mal die Stammdaten und nehmen Sie Korrekturen vor (manchmal tritt immer noch ein Fehler auf und die Ursache ist ein Codefehler).
Ich denke nicht, dass dies eine gute Sache ist, aber ich profitiere auch von der Gewissheit, die Ergebnisse mit bestimmten Zahlen zu vergleichen.
Wenn ich beschäftigt bin, ist es schwierig, mit der Reparatur zu beginnen.
Infolgedessen senden Jenkins Ihnen immer Fehlerbenachrichtigungen.
Dies ist nicht sinnvoll, um den Test zu automatisieren. Daher hat das Team beschlossen, ihn mindestens zu beheben, sobald ein API-Testfehler auftritt.
Wir versuchen jedoch, klassenbasierte Tests so weit wie möglich zu unterstützen.
Abhängig von der Person, die den Test schreibt, kann es sich lediglich um eine Überprüfung handeln, ob kein Fehler auftritt, oder um einen Test, bei dem die Ergebnisse im Detail verglichen werden.
Wenn Sie ein Projekt starten, ist es möglicherweise besser, die Granularität dieses Bereichs anzupassen.
Wenn sich die Daten noch in einem temporären Zustand befinden, schreiben Sie einen Test, damit das Programm normal funktioniert, und erstellen Sie beim Erstellen der Daten einen separaten Test für die Granularität des Integrationstests. Ist es nicht? Ich dachte.
Der methodenbasierte Test dauert etwa eine Stunde.
Es befindet sich noch in der Entwicklung, daher habe ich noch etwas Zeit, aber ich kann es mir nicht leisten, während der Veröffentlichung einen Fehler zu finden, ihn zu beheben, eine Stunde lang zu testen und ihn dann in der Produktion wiederzugeben.
Was ist los?
Rückblickend auf die bisherige Entwicklung (obwohl sie sich noch in der Entwicklung befindet) wollte ich schließlich sagen, dass der Test gut ist. Es kann schmerzhaft sein. Die Testwartung ist mühsam. Aber wenn Sie den Test bestehen, werden Sie sich glücklich fühlen. Nach der Veröffentlichung tritt jedes Mal, wenn ich es behebe, ein weiterer Fehler auf ... Ich glaube nicht, dass er dank dieses Tests vermieden werden kann. Wenn Sie noch keinen Test geschrieben haben, schreiben wir einen Test.
Dieses Mal habe ich über die Gewährleistung der Sicherheit des Codes geschrieben, aber das nächste Mal werde ich über die Leistungsverbesserung schreiben. Außerdem werde ich untersuchen, ob es einen besser aussehenden Schreibstil gibt.
Recommended Posts