Bewährte Verfahren für die Benennung von Unit- und Integrationstestmethoden?

Question

Ich habe vor kurzem eine Anwendung geerbt, die von verschiedenen Personen zu verschiedenen Zeiten geschrieben wurde, und suche nach einer Anleitung, wie man sie standardisieren kann.

Answer 1

Unter der Annahme, dass NUnit:

[Test]
public void ObjectUnderTest_StateChanged_Consequence()
{
    Assert.That(tra_la_la);
}

[Test]
public void ObjectUnderTest_Behaviour_Consequence()
{
    Assert.That(tra_la_la);
}

zum Beispiel:

[Test]
public void WifeIsTired_TakeWifeToDinner_WifeIsGrateful()
{
    Assert.That(tra_la_la);
}

[Test]
public void WifeIsTired_MentionNewGirlfriend_WifeGetsHalf()
{
    Assert.That(tra_la_la);
}

Answer 2

Ich schreibe einfach, wozu es gut ist. Es ist ja nicht so, dass man die Namen irgendwo anders eintippen muss, also habe ich einen testWibbleDoesNotThrowAnExceptionIfPassedAFrobulator ist kein Problem. Alles, was ein Test ist, beginnt natürlich mit "Test".

Answer 3

Es gibt keinen Standard als solchen, verschiedene Leute/Orte haben unterschiedliche Systeme. Das Wichtigste ist, dass Sie Stick zu einer Norm.

Ich persönlich bin ein Fan der folgenden - Beispielcode in C #, aber sehr nah an Java, die gleichen Regeln gelten:

[Test]
public void person_should_say_hello()
{
     // Arrange
     var person = new Person();
     // Act
     string result = person.SayHello();
     // Assert
     Assert(..., "The person did not say hello correctly!");
}

Ausdrücklich

Der Testname sollte den Namen der zu testenden Klasse enthalten. In diesem Beispiel ist die zu testende Klasse Person . Der Testname sollte auch den Namen der Methode enthalten, die getestet wird. Wenn der Test fehlschlägt, wissen Sie so zumindest, wo Sie das Problem suchen müssen. Ich würde auch empfehlen, die AAA - Anordnen, Handeln, Behaupten Regel wird sichergestellt, dass Ihre Tests leicht zu lesen und nachzuvollziehen sind.

Freundliche Fehlermeldungen

Wenn es darum geht, ein Ergebnis/einen Zustand zu bestätigen, ist es sinnvoll, eine optionale Nachricht einzufügen. Dies macht es einfacher, wenn ein Test fehlschlägt, insbesondere wenn er als Teil eines Build-Prozesses oder über ein externes Tool ausgeführt wird.

Unterstreichungen

Die letzte (wenn auch optionale) Haltung, die ich vertrete, ist die Verwendung von Unterstrichen für Testnamen. Während ich kein Fan von Unterstrichen in Produktionscode bin, ist ihre Verwendung in Testnamen nützlich, da Testnamen oft viel länger sind. Ein schneller Blick auf einen Testnamen, der Unterstriche verwendet, erweist sich als viel lesbarer, obwohl dies subjektiv ist und die Quelle vieler Debatten in Bezug auf Unit-Testing-Praktiken ist.

Integrationstests

Für die Integrationstests gelten dieselben Standards, der einzige Unterschied besteht darin, wo diese Tests durchgeführt werden devrait von den Einheitstests getrennt sein. In dem obigen Beispielcode würde die Testklasse heißen PersonTests und befindet sich in einer Datei namens PersonTests.cs . Die Integrationstests würden in ähnlicher Weise benannt werden - PersonIntegrationTests mit Sitz in PersonIntegrationTests.cs . Für diese Tests kann dasselbe Projekt verwendet werden, wobei jedoch darauf zu achten ist, dass sie sich in getrennten Verzeichnissen befinden.

Answer 4

Es ist lehrreich, sich mit BDD (Behavioral Driven Development) und dieser Blogbeitrag im Besonderen.

BDD konzentriert sich im Wesentlichen auf Komponenten und was sie devrait tun. Folglich wirkt es sich direkt darauf aus, wie Sie Ihre Tests benennen/strukturieren, und auf den Code, den sie verwenden, um Bedingungen aufzustellen und zu validieren. BDD ermöglicht es nicht nur den Entwicklern, die Tests zu lesen/schreiben, sondern auch nicht-technischen Teammitgliedern (Geschäftsanalysten usw.), einen Beitrag zu leisten, indem sie die Tests spezifizieren und sie validieren.

Answer 5

Ich bin auf zwei gute Vorschläge gestoßen. Links hier: http://slott-softwarearchitect.blogspot.com/2009/10/unit-test-naming.html

http://weblogs.asp.net/rosherove/archive/2005/04/03/TestNamingStandards.aspx

http://openmrs.org/wiki/Unit_Testing_with_@sollte