Ich habe Situation, in der es mehrere Testfälle gibt, die eine allgemeine Methode verwenden. Um DRY zu vermeiden (wiederhole dich nicht) lege ich sie in eine Util-Klasse. So, jetzt muss ich einen Testfall für die Util-Klasse schreiben. Die gesamte util-Klasse enthält eine bestimmte Datei und gibt ihren Inhalt zurück.Muss ich Testfall für util Klassen schreiben, die von Testfall verwendet werden
Danke, Sriram
Die allgemeine Regel lautet: Test, wie Sie so viel brauchen, bis Sie zufrieden sind, dass Ihr Programm korrekt ist.
Wie würde eine falsche Dienstprogrammklasse für das Testen das Verhalten des Programms beeinträchtigen? Ich weiß nichts über Ihr spezifisches Programm, aber eine inkorrekte Dienstklasse zum Testen kann die Korrektheit Ihres Programms nicht beeinflussen. Stattdessen kann es Sie denken lassen, dass Ihr Programm korrekt ist, wenn es nicht wirklich ist, oder denken, dass es falsch ist, wenn es wirklich korrekt ist. Also mein Instinkt für Utility-Klassen zum Testen ist nicht, um die Klasse direkt zu testen, sondern um einen mentalen Beweisprozess zu durchlaufen und festzustellen, dass die Hilfsmethoden korrekt sind und mich daher nicht in einen Irrglauben über Programmkorrektheit trickst.
Besonders in Ihrem Fall, wo die Dienstprogrammklasse nur eine Datei liest und ihren Inhalt zurückgibt, müssen Sie wahrscheinlich keine Testfälle schreiben. Code, der so einfach sein sollte, sollte leicht zu überprüfen sein, so dass die mental bewiesene Korrektheit billiger ist als das Schreiben von Testfällen.
N.B. Es ist ziemlich hilfreich, einen mentalen Beweisprozess für den gesamten Code durchzuführen. Einige der trendigen "Tricks" zum Debuggen, wie rubber duck debugging, sind wirklich nur Möglichkeiten, sich zu beweisen (zumindest in deinem Kopf), dass Teile deines Codes korrekt oder zumindest nicht eklatant falsch sind.
gut sagt nicht TDD immer wir müssen 100% Code-Abdeckung bekommen? Ich möchte sagen, dass, wenn der Entwickler ein Ermessen hat zu entscheiden, was wichtig ist zu testen und was nicht wichtig ist, ich glaube, dass es gefährlich ist. Denn ein Entwickler ist doch ein Mensch und anfällig für Fehler? Was sagst du? – sriram
@sriram Das Ziel von TDD ist nicht 100% Codeabdeckung - es ist korrekter Code. 100% Codeabdeckung ist * ein Mittel zum Zweck *, kein Selbstzweck. Ein Entwickler ist menschlich und anfällig für Fehler, aber wenn Sie die Richtigkeit beweisen können, ob mental oder in einer dauerhafteren Form (Kommentare, Papier usw.), haben Sie etwas Besseres als einen Komponententest. Ein Komponententest zeigt die Korrektheit der Eingaben an, die der Komponententest an den von Ihnen getesteten Code übergibt, aber ein Korrektheitsbeweis zeigt die Korrektheit für * alle Eingaben * an, was strenggenommen besser ist. –
Danke! Stimme völlig zu. – sriram