Vor kurzem habe ich die folgende Konvention für die Benennung meiner Tests, ihrer Klassen und der darin enthaltenen Projekte entwickelt, um ihre Beschreibbarkeit zu maximieren:
Nehmen wir an, ich teste die Settings
Klasse in einem Projekt in der MyApp.Serialization
Namensraum.
Zuerst werde ich ein Testprojekt mit der MyApp.Serialization.Tests
Namensraum.
Innerhalb dieses Projekts und natürlich des Namespaces werde ich eine Klasse namens IfSettings
(gespeichert als IfSettings.cs ).
Nehmen wir an, ich teste die SaveStrings()
Methode. -> Ich werde den Test benennen CanSaveStrings()
.
Wenn ich diesen Test ausführe, wird die folgende Überschrift angezeigt:
MyApp.Serialization.Tests.IfSettings.CanSaveStrings
Ich denke, das sagt mir sehr gut, was es testet.
Natürlich ist es nützlich, dass im Englischen das Substantiv "Tests" das gleiche ist wie das Verb "tests".
Bei der Benennung der Tests sind Ihrer Kreativität keine Grenzen gesetzt, damit wir vollständige Satzüberschriften für sie erhalten.
Normalerweise müssen die Testnamen mit einem Verb beginnen.
Beispiele hierfür sind:
- Erkennt (z.B.
DetectsInvalidUserInput
)
- Würfe (z. B.
ThrowsOnNotFound
)
- Wille (z.B.
WillCloseTheDatabaseAfterTheTransaction
)
usw.
Eine weitere Möglichkeit ist die Verwendung von "dass" anstelle von "wenn".
Letzteres erspart mir allerdings Tastatureingaben und beschreibt genauer, was ich tue, da ich es nicht weiß, que das getestete Verhalten ist vorhanden, aber ich teste wenn es ist.
[ bearbeiten ]
Nachdem ich obige Namenskonvention nun schon etwas länger verwende, habe ich festgestellt, dass die Si Präfix kann verwirrend sein, wenn man mit Schnittstellen arbeitet. Zufälligerweise ist die Testklasse IfSerializer.cs sieht der Schnittstelle sehr ähnlich ISerializer.cs in der Registerkarte "Dateien öffnen". Dies kann sehr störend sein, wenn man zwischen den Tests, der getesteten Klasse und ihrer Schnittstelle hin und her wechselt. Als Ergebnis würde ich nun wählen Das en Si als Präfix.
Zusätzlich verwende ich jetzt - nur für Methoden in meinen Testklassen, da es nirgendwo sonst als Best Practice angesehen wird - das "_", um Wörter in meinen Testmethodennamen zu trennen, wie in:
[Test] public void detects_invalid_User_Input()
Ich finde, dass dies leichter zu lesen ist.
[ Bearbeiten beenden ]
Ich hoffe, dass dies einige weitere Ideen hervorbringt, da ich die Benennung von Tests für sehr wichtig halte, da man dadurch viel Zeit sparen kann, die man sonst damit verbracht hätte, zu verstehen, was die Tests tun (z.B. wenn man ein Projekt nach einer längeren Pause wieder aufnimmt).
1 Stimmen
Siehe hier: stackoverflow.com/questions/96297/
2 Stimmen
Dies ist zwar keine Antwort auf Ihre Frage, aber es lohnt sich, es zu lesen: haacked.com/archive/2012/01/02/structuring-unit-tests.aspx
6 Stimmen
Google Style Guide sagt:
test<MethodUnderTest>_<state>
z.B.testPop_emptyStack
google-styleguide.googlecode.com/svn/trunk/javaguide.html 5.2.3 Methodennamen. Im Zweifelsfall sollte man Google folgen.5 Stimmen
@CiroSantilli Und im nächsten Satz heißt es: "Es gibt keinen einzig richtigen Weg, Testmethoden zu benennen". Stellen Sie sich vor.