Für Tests mit Schreibeinheiten weiß ich, dass es sehr beliebt ist, Testmethoden zu schreiben, die aussehen wie
%Vor%Das macht zwar leicht zu sehen, wofür der Test testet, aber ich denke, er sieht hässlich aus und wird in der automatisch generierten Dokumentation (wie Sandcastle oder Javadoc) nicht gut dargestellt.
Ich bin daran interessiert zu sehen, was die Leute denken, wenn sie ein Benennungsschema verwenden, bei dem es sich um die zu testende Methode und den Unterstreichtest und dann um die Testnummer handelt. Dann verwenden Sie das XML-Code-Dokument (.net) oder die Javadoc-Kommentare, um zu beschreiben, was getestet wird.
%Vor%indem ich das tue, kann ich meine Tests leicht mit den Methoden gruppieren, die sie testen, ich kann sehen, wie ich für eine gegebene Methode testen kann, und ich habe immer noch eine vollständige Beschreibung dessen, was getestet wird.
Wir haben einige Regressionstests, die gegen eine Datenquelle (eine XML-Datei) laufen, und diese Datei kann von jemandem ohne Zugriff auf den Quellcode (QA-Affe) aktualisiert werden und sie müssen lesen können, was getestet wird und wo, um die Datenquellen zu aktualisieren.
Was ist mit dem Ändern
? %Vor%bis
%Vor% und benennen Sie etwas wie User
Ich bevorzuge die "long names" -Version - obwohl ich nur beschreiben soll, was passiert. Wenn der Test eine Beschreibung von benötigt, warum es passiert, gebe ich das in einen Kommentar (mit einer Fehlernummer, falls zutreffend).
Mit dem langen Namen wird viel klarer, was passiert ist, wenn Sie eine Mail (oder was auch immer) erhalten, die Ihnen sagt, welche Tests fehlgeschlagen sind.
Ich würde es in Bezug darauf schreiben, was es tun sollte obwohl:
%Vor%Ich kaufe nicht das Argument, dass es in automatisch generierter Dokumentation schlecht aussieht - warum führen Sie JavaDoc überhaupt über die Tests aus? Ich kann nicht sagen, dass ich das jemals gemacht habe, oder wollte erzeugte Dokumentation. Vorausgesetzt, dass Testmethoden in der Regel keine Parameter haben und nichts zurückgeben, kann der Methodenname sie in angemessener Weise beschreiben. Dies sind alle Informationen, die Sie benötigen. Der Test-Runner sollte in der Lage sein, die Tests aufzulisten, die er ausführt, oder die IDE kann Ihnen anzeigen, was verfügbar ist. Ich finde das bequemer als das Navigieren über HTML - der Browser hat keinen "Suchtyp", mit dem ich nur die ersten Buchstaben jedes Wortes eingeben kann, zum Beispiel ...
Erscheint die Dokumentation in Ihrem Test Runner? Wenn nicht, ist das ein guter Grund, stattdessen lange beschreibende Namen zu verwenden.
Persönlich bevorzuge ich lange Namen und sehe selten die Notwendigkeit, Kommentare zu Tests hinzuzufügen.
Ich habe meine Dissertation zu einem verwandten Thema gemacht, also hier sind meine zwei Cents: Jedes Mal, wenn Sie sich auf Dokumentation verlassen, um etwas zu übermitteln, das nicht in Ihrer Methodensignatur ist, nehmen Sie das riesige Risiko auf, dass niemand die Dokumentation lesen würde .
Wenn Entwickler nach etwas Bestimmtem suchen (z. B. nach einer langen Liste von Methoden in einer Klasse suchen, um zu sehen, ob das, wonach sie suchen, bereits vorhanden ist), werden sich die meisten nicht die Mühe machen, die Dokumentation zu lesen. Sie möchten sich mit einer Art von Informationen befassen, die sie leicht sehen und vergleichen können (z. B. Namen), anstatt mit der Weiterleitung zu anderen Materialien beginnen zu müssen (z. B. lange genug schweben, um die JavaDocs zu sehen).
Ich würde Ihnen dringend empfehlen, alles Wichtige in Ihrer Unterschrift zu übermitteln.
Ich schlage kleinere, fokussiertere (Test-) Klassen vor.
Warum sollten Sie Javadoc-Tests machen?
Als Gruppe denken wir, wie man ein hybrides Namensschema wie dieses macht
%Vor%und wir bekommen das Beste aus beiden.
Tags und Links java .net unit-testing