Unter it happens with private methods kann die Dokumentation der Komponententestmethoden nur von wem gesehen werden, der Zugriff auf den Quellcode hat. Lohnt es sich, den Aufwand dafür auszugeben?Sollte ich meine Unit-Testmethoden dokumentieren?
Durch Dokumentation meine ich so etwas wie (aber eher deskriptiv):
/// <summary>
///A test for SomeClass.SomeMethod
///</summary>
[TestMethod()]
public void SomeMethodTest()
{
}
Komponententests sollten darauf abzielen, selbstbeschreibend zu sein, aber es wird immer Fälle geben, in denen dieses Ziel nicht erreicht werden kann und daher eine Beschreibung dessen, was geschrieben wurde, fällig ist.
Mit anderen Worten, versuchen Sie, Ihre Komponententests so zu machen, dass sie keine Dokumentation benötigen, aber wenn sie es brauchen, schreiben Sie es!
würde ich eher zu geneigt sein, zu sagen, dass Sie Ihre Testverfahren in einer Weise nennen sollte, die in Bezug auf expressive ist, was es testet: SomeMethodWillBehaveThisWayWhenCalledWithTheseParameters() obwohl einige Leute das kontrovers finden können.
Ich entdeckte gerade die "when_ * condition * _should_ * doThis *" Benennung für die Methoden. –
Ein beschreibender Funktionsname ist hilfreich, aber das Einfügen in ganze Sätze ist ein bisschen zu viel für mich. – stimpie
Einverstanden. Normalerweise nenne ich Komponententests mit S/S/R: Subjekt, Szenario, erwartetes Ergebnis.(http://blog.codeville.net/2009/08/24/writing-great-unit-tests-best-and-worst-practices/) Bedeutet nicht wirklich, dass Sie Ihren Code nicht dokumentieren sollten. –
Sie sollten den gesamten Code dokumentieren.
Für Unit-Tests, sage ich normalerweise, was ich testen, und wie es getestet wird. Putting "Test für Class.SomeMethod" ist nicht sehr hilfreich.
Oh ja!
Auch wenn "wer Zugriff auf den Quellcode hat" nie jemand anderes als Sie sein wird, wird es nicht das gleiche sein, das Sie in einem Jahr (oder sogar einem Monat) ansehen, vertrauen Sie mir Dazu :-)
+1 der mörderische maniac mantainer, der weiß, wo du wohnst, bist du wahrscheinlich selbst! – SingleNegationElimination
Ich denke, es ist gut, Komponententests zu dokumentieren, mein Hauptgrund dafür ist, dass Sie erklären können, warum bestimmte Funktionen getestet werden. Meine Komponententests neigen dazu, mit allen möglichen seltsamen extremen oder unerwarteten Parametern zu enden.
Wenn ein Test fehlschlägt, weiß ein zukünftiger Programmierer (oder Sie mit einem schlechten Speicher), warum eine Funktionalität getestet/implementiert wurde.
Ja. Tests mögen sich als selbstdokumentierend erweisen, aber die Faltungen, die Sie manchmal durchlaufen müssen, um aussagekräftige Testdaten zu generieren, bedeuten, dass für den späteren Betreuer, der vielleicht nur SIE ist, nicht alles sofort offensichtlich ist. Machen Sie Ihr Leben leichter - dokumentieren Sie Ihren Code.
Ein Komponententest sollte einfach genug und ausführlich genug sein, um das Verständnis zu erleichtern. Wenn Sie Ihren Komponententest kommentieren müssen, sollten Sie vielleicht seinen Namen ändern, oder vielleicht sollten Sie es in kleinere Methoden umgestalten.
Refactoring-Test ist eine gute Praxis, Sie müssen Ihre Tests tatsächlich umgestalten, oder sie werden unmöglich zu warten.
Kommentare, wie ich sie sehe, sind fast immer ein Zeichen, dass Sie das Stück Code, das Sie kommentieren müssen, umgestalten sollten. Was für Produktionscode gilt, gilt für Testcode.
Die meisten Komponententests sollten keine Dokumentation benötigen. Der Name sollte klarstellen, welche Methode sie testen und geben einen Hinweis auf die erwarteten Ergebnisse. Der Code sollte einfach und klar sein. Komponententests sollten keine Geschäftsregeln implementieren, daher ist die Dokumentation des "Warum" normalerweise nicht notwendig.
In dem seltenen Fall, dass ein Test komplex genug sein muss, um Kommentare zu rechtfertigen, sollten sie wie jeder andere Code dokumentiert werden.
Für MSTest (IDK, wenn NUnit etwas Ähnliches hat) ist es nützlich ein DescriptionAttribute für jede Testmethode, da sie in der Test Results Panel auf Visual Studio angezeigt werden. Besser lesbar als die Namenskonvention WhenThisHappenShouldHappenThis.
Ich finde die durch den Komponententest ausgedruckte Nachricht, wenn es im Allgemeinen ausreicht. Zum Beispiel in Perl:
is(compare_bitstrings($bs1, $bs2, $gen), 1, 'compare_bitstrings - bs1 > bs2');
Gibt
ok 74 - compare_bitstrings - bs1 > bs2
wenn erfolgreich ausgeführt werden. Das sagt mir, was ich versuche und was die Antwort sein soll.
Gut, aber wir wissen, dass dies nicht für alle Unit-Test-Frameworks gilt. –
Ja. Ich denke, dass das Dokumentieren von Komponententests eine gute Idee ist, wenn Sie während der Entwicklung nicht nur die API Ihrer Produktionsklassen modifizieren, sondern ein internes Verhalten, das einige Tests zum Scheitern bringt, dann spart es eine Menge Zeit für die Navigation Testen Sie den Code, lesen Sie die Dokumentation zum Komponententest und stellen Sie fest, ob Sie erwartet hätten, dass der Test fehlschlägt, wenn Sie sich in letzter Zeit verändert haben oder etwas Subtileres vorkommt.
Ohne diese Dokumentation müssten Sie herausfinden, was der Test aus seinem Namen und den Kommentaren/Code innerhalb des Tests macht.
Beachten Sie, dass wenn Sie einfach nur den Namen des Komponententests in der Dokumentation umschreiben, dies nicht sehr nützlich ist und ich bleibe dabei, dem Einheitentest nur einen beschreibenden Namen zu geben (dh die Dokumentation sollte ist ausführlicher als der Name des Einheitentests)
Absolut !! Ihre Komponententests sollten genauso gut dokumentiert werden wie Ihr tatsächlicher Code. Aus keinem anderen Grund als dem nicht ungewöhnlichen Umstand, nicht zu wissen, ob es Ihr Code oder Ihr Test ist, der den Fehler hat.
Wenn ich Tests schreibe, bevorzuge ich einen Kommentar für den Test, gefolgt von einem beschreibenden Namen der Testmethode (wie S/S/R-Format in den Kommentaren einer anderen Antwort erwähnt), weil es eine Gewohnheit meiner Kollegen Entwickler und ich habe in, als wir mit CPPUNIT mit C++ angefangen haben. Während ich in C# experimentiere, ist der von Lucas in seiner Antwort erwähnte Punkt ein guter - wenn das Framework es erlaubt, ist das Beschreibungsfeld, das im Quelltext UND den Ergebnissen verwendet werden kann, sehr praktisch, und ich würde einen Kommentar bevorzugen Format, das an vielen Orten wie diesem verwendet werden kann.
Alles was gesagt wird, ich denke, dass Sie schauen müssen, wie Sie oder Ihr Entwicklungsteam typischerweise Code-Kommentare behandeln. Sind Leute im allgemeinen Schwung, wo sie Kommentare aktualisieren, wenn der Code repariert ist, refaktorisiert? Ist das Projekt kleiner und wird es immer die gleichen wenigen Entwickler geben, die eng zusammenarbeiten?
Die Projekte, an denen ich arbeite, sind größer und können je nach Status von einem Team in der Nähe, einem Remote-Team oder gemeinsam entwickelt oder komplett an einen Anbieter übergeben werden. In meinen Szenarien versuchen wir, die Zeit zu verbringen, um die Dokumentation in Produktion und Testcode für diejenigen zu dokumentieren und zu pflegen, die in der Zukunft mitkommen werden.
Wenn Kommentare in der Regel ein Nachdenken sind, so sehr es mich auch schmerzen mag, wenn es eine Chance gibt, dass Ihre Kommentare mit dem tatsächlichen Code/den Tests nicht mehr aktuell sind, ergibt das möglicherweise keinen Sinn um zu versuchen, den Status quo zu ändern.
Übrigens glaube ich, dass der gesamte Code darauf abzielen sollte, selbstbeschreibend zu sein und Kommentare nur dort zu haben, wo Sie nicht in der Lage waren, den Code zu erhalten, um die ganze Geschichte zu erzählen. Komponententests machen dies nur deutlicher (weil Unit-Test-Code in der Regel einfacher ist). –