Unit-Test Namensgebung Best Practices [geschlossen]

Question

Was sind die besten Praktiken für die Benennung Einheit Testklassen und Testmethoden?

Dies wurde am SO vorher besprochen, unter Was einige beliebten Namenskonventionen für Unit-Tests sind?

Ich weiß nicht, ob dies ein sehr guter Ansatz, aber zur Zeit in meinen Testprojekten, ich habe eine Eins-zu-Eins-Zuordnungen zwischen dem einzelnen Produktionsklasse und einer Testklasse, z.B. Product und ProductTest.

In meiner Testklasse Ich habe dann Methoden mit den Namen der Methoden I-Tests sind, ein Unterstriches, und dann die Situation und was ich erwarte, dass das geschehen kann, zum Beispiel Save_ShouldThrowExceptionWithNullName().

Answer 1

Ich mag Roy Osherove der Namensgebung Strategie , ist es wie folgt vor:

[UnitOfWork_StateUnderTest_ExpectedBehavior]

Es hat alle Informationen über die Methodennamen benötigt und in strukturierter Form.

Die Arbeitseinheit kann als ein einziges Verfahren so klein sein, eine Klasse oder so groß wie mehrere Klassen. Es sollte alle Dinge darstellen, die in diesem Testfall getestet werden und sind unter Kontrolle.

Bei Baugruppen verwende ich die typische .Tests enden, was meiner Meinung nach ziemlich weit verbreitet ist und das gleiche für die Klassen (mit der Endung Tests):

[NameOfTheClassUnderTestTests]

Bisher ich Fixture als Suffix statt Tests verwendet, aber ich denke, das letztere ist häufiger, dann änderte ich die Namensgebung Strategie.

Answer 2

Ich mag der "sollte" folgen Namensgebung Standard für Tests , während der Namensgebung Prüfadapter nach der im Test befindlichen Einheit (dh die Klasse ).

Zur Veranschaulichung (unter Verwendung von C # und NUnit):

[TestFixture]
public class BankAccountTests
{
  [Test]
  public void Should_Increase_Balance_When_Deposit_Is_Made()
  {
     var bankAccount = new BankAccount();
     bankAccount.Deposit(100);
     Assert.That(bankAccount.Balance, Is.EqualTo(100));
  }
}

Warum "sollte"

Ich finde, dass es den Test Schriftsteller zwingt den Test mit einem Satz entlang der Linien zu nennen „Sollte [in einem gewissen Zustand sein] [nach / vor / when] [Aktion findet]“

Ja, das Schreiben „Soll“ überall tut etwas eintönig, aber wie gesagt es zwingt Schriftsteller in der richtigen Art und Weise zu denken (so kann für Anfänger gut sein). Außerdem ist es im allgemeinen zu einem lesbaren Englisch Testnamen.

Update :

Ich habe bemerkt, dass Jimmy Bogard ist auch ein Fan von 'sollte' und hat sogar eine Unit-Test-Bibliothek mit dem Namen Sollte .

Update (4 Jahre später ...)

Für Interessenten, mein Ansatz zur Namensgebung Tests hat sich im Laufe der Jahre entwickelt hat. die eines der Themen, mit Soll Muster, das ich oben als nicht einfach beschreiben auf einem Blick, welche Methode wissen ist, unter Test. Für OOP ich denke, es macht mehr Sinn, den Test-Namen mit dem Verfahren unter Test zu starten. Für eine gut gestaltete Klasse in lesbaren Testmethodennamen führen soll. Ich verwende jetzt ein ähnliches Format wie <method>_Should<expected>_When<condition>. Offensichtlich je nach Kontext Sie möchten die Should / Wenn Verben etwas besser geeignet ersetzen. Beispiel: Deposit_ShouldIncreaseBalance_WhenGivenPositiveValue()

Answer 3

Ich mag diese Namensgebung Stil:

OrdersShouldBeCreated();
OrdersWithNoProductsShouldFail();

und so weiter. Es macht wirklich klar zu einem nicht-Tester, was das Problem ist.

Answer 4

Kent Beck schlägt vor:

• Eine Prüfvorrichtung pro ‚Einheit‘ (Klasse Ihres Programms). Prüfadapter sind Klassen selbst. Die Prüfvorrichtung Name sollte sein:

  [name of your 'unit']Tests
  

• Die Testfälle (die Prüfvorrichtung Methoden) haben Namen wie:

  test[feature being tested]
  

Zum Beispiel der folgenden Klasse mit:

class Person {
    int calculateAge() { ... }

    // other methods and properties
}

Eine Testvorrichtung wäre:

class PersonTests {

    testAgeCalculationWithNoBirthDate() { ... }

    // or

    testCalculateAge() { ... }
}

Answer 5

Klassennamen . Für Prüfadapter Namen finde ich, dass „Test“ in der allgegenwärtigen Sprache vielen Domains durchaus üblich ist. Zum Beispiel in einer Engineering-Domäne: StressTest und in einer Kosmetik-Domain: SkinTest. Leider mit Kent anderer Meinung zu sein, aber unter Verwendung von „Test“ in meinem Prüfvorrichtungen (StressTestTest?) Ist verwirrend.

„Unit“ wird verwendet, auch eine Menge in Domänen. Z.B. MeasurementUnit. Ist eine Klasse namens ein Test der „Messung“ MeasurementUnitTest oder „MeasurementUnit“?

Deshalb mag ich das „Qa“ Präfix verwenden, für alle meine Testklassen. Z.B. QaSkinTest und QaMeasurementUnit. Es wird nie mit Domänenobjekten und mit einem Präfix eher als ein Suffix bedeutet verwirrt, dass alle Prüfvorrichtungen zusammen visuell leben (nützlich, wenn Sie Fälschungen oder andere Support-Klassen in Ihrem Testprojekt haben)

Namespaces . Ich arbeite in C # und ich meine Testklassen im gleichen Namensraum wie die Klasse, die sie testen. Es ist bequemer, als separate Testnamensräume haben. Natürlich sind die Testklassen in einem anderen Projekt.

Testmethodennamen . Ich mag meine Methoden nennen WhenXXX_ExpectYYY. Es macht die Voraussetzung klar, und hilft bei der automatisierten Dokumentation (a la TestDox). Dies ist vergleichbar mit der Beratung über den Google-Tests Blog, aber mit mehr Trennung von Voraussetzungen und Erwartungen. Zum Beispiel:

WhenDivisorIsNonZero_ExpectDivisionResult
WhenDivisorIsZero_ExpectError
WhenInventoryIsBelowOrderQty_ExpectBackOrder
WhenInventoryIsAboveOrderQty_ExpectReducedInventory

Answer 6

ich Given-Wenn-Dann Konzept. Werfen Sie einen Blick auf diesen kurzen Artikel http://cakebaker.42dh.com / 2009/05/28 / given-when-then / . Artikel beschreibt dieses Konzept in Bezug auf BDD, aber man kann es in TDD als auch verwenden, ohne Änderungen.

Answer 7

Siehe auch: http://googletesting.blogspot.com/2007/02 /tott-naming-unit-tests-responsibly.html

Für Testmethodennamen, finde ich persönlich mit ausführlich und selbst dokumentiert Namen sehr nützlich (neben Javadoc Kommentare, die weiter erläutern, was der Test tut).

Answer 8

Ich glaube, eines der wichtigsten Dinge, die in Ihrer Namenskonvention in Einklang stehen (und stimmen sie mit anderen Mitgliedern Ihres Teams). Zu oft sehe ich jede Menge verschiedener Konventionen im gleichen Projekt verwendet.

Answer 9

Ich kam vor kurzem mit der folgenden Konvention für meine Tests zu nennen, ihre Klassen und enthalten Projekte, um ihre descriptivenes zu maximieren:

Lassen Sie uns sagen Ich teste die Einstellungen Klasse in einem Projekt in der MyApp.Serialization Namespace.

Zuerst werde ich ein Testprojekt mit der MyApp.Serialization.Tests Namespace erstellen.

Im Rahmen dieses Projektes und natürlich der Namensraum I eine Klasse erstellen, wird genannt IfSettings (gespeichert als IfSettings.cs).

Lassen Sie uns sagen Ich teste die SaveStrings () Methode. -> Ich nenne den Test CanSaveStrings ()

.

Wenn ich diesen Test ausführen wird es die folgende Überschrift zeigen:

MyApp.Serialization.Tests.IfSettings.CanSaveStrings

Ich denke, das sagt mir sehr gut, was es Tests ist.

Natürlich ist es sinnvoll, dass in Englisch das Substantiv „Tests“ ist das gleiche wie das Verb „Tests“.

Es gibt keine Begrenzung auf Ihre Kreativität, die Tests bei der Benennung, so dass wir die vollen Satz Schriften für sich zu erhalten.

Normalerweise sind die Testnames wird mit einem Verb beginnen müssen.

Beispiele hierfür sind:

• Ermittelt (z DetectsInvalidUserInput)
• Wirft (z ThrowsOnNotFound)
• Will (z WillCloseTheDatabaseAfterTheTransaction)

etc.

Eine weitere Option ist „dass“ anstelle von „if“ zu verwenden.

Letzteres erspart mir Tastatureingaben obwohl und beschreibt mehr genau, was ich tue, weil ich nicht weiß, , die das getestete Verhalten vorhanden ist, aber ich testen < strong> , wenn ist.

[ Bearbeiten ]

Nach der Verwendung von oben Konvention für ein wenig länger zu benennen jetzt habe ich festgestellt, dass die Wenn Präfix kann verwirrend sein, wenn sie mit Schnittstellen arbeiten. Es passiert einfach so, dass die Testklasse IfSerializer.cs auf die Schnittstelle sieht sehr ähnlich wie ISerializer.cs in der "Open Files Tab". Dies kann sehr ärgerlich, wenn hin und her zwischen den Tests Schalt, wobei die Klasse getestet und seine Schnittstelle. Als Ergebnis würde ich jetzt wählen Das über Wenn als Präfix.

Außerdem verwende ich jetzt - nur für Methoden in meinen Testklassen, da es nicht am beste Praxis anderswo betrachtet wird - die „_“ zu Worten in meinen Test-Methode Namen zu trennen, wie in:

• [Test] public void detects_invalid_User_Input () *

Das finde ich einfacher zu lesen.

[ Ende Bearbeiten ]

Ich hoffe, das noch einige Ideen laicht, da ich Namensgebung Tests von großer Bedeutung betrachten, wie es Ihnen eine Menge Zeit sparen, die sonst versucht worden wären, verbracht zu verstehen, was die Tests machen (zB nach einem Projekt nach einer Wiederaufnahme erweiterte Pause).

Answer 10

In VS + NUnit Ich schaffe in der Regel Ordner in meinem Projekt zu gruppieren Funktionstests zusammen. Dann erstelle ich Einheit Prüfadapter Klassen und benennen Sie diese nach der Art der Funktionalität I-Tests sind. Die [Test] Methoden sind entlang der Linien von Can_add_user_to_domain benannt:

- MyUnitTestProject   
  + FTPServerTests <- Folder
   + UserManagerTests <- Test Fixture Class
     - Can_add_user_to_domain  <- Test methods
     - Can_delete_user_from_domain
     - Can_reset_password

Answer 11

Ich soll hinzufügen, dass die Ihre Tests in der gleichen Verpackung zu halten, sondern in einem parallelen Verzeichnis der Quelle getestet werden eliminiert das aufblasen des Codes, sobald Du bereit, es zu implementieren, ohne ein Bündel ausschließen Muster zu tun.

Ich persönlich mag die besten Praktiken beschrieben in "JUnit Pocket Guide" ... es ist schwer, ein Buch von dem Co-Autor von JUnit geschrieben zu schlagen!

Answer 12

der Name des der Testfall für die Klasse Foo sollte FooTestCase oder etwas ähnliches (FooIntegrationTestCase oder FooAcceptanceTestCase) sein - da es sich um ein Testfall ist. siehe http://xunitpatterns.com/ für einige Standardnamenskonventionen wie Test, Testfall, Prüfadapter, Testverfahren etc.