Was sind einige beliebte Namenskonventionen für Unit-Tests? [geschlossen]

Allgemeines

• Befolgen Sie für alle Tests die gleichen Standards.
• Machen Sie sich klar, was jeder Testzustand ist.
• Seien Sie genau über das erwartete Verhalten.

Beispiele

1) MethodName_StateUnderTest_ExpectedBehavior

Public void Sum_NegativeNumberAs1stParam_ExceptionThrown() 

Public void Sum_NegativeNumberAs2ndParam_ExceptionThrown () 

Public void Sum_simpleValues_Calculated ()

Quelle: Namensstandards für Unit Tests

2) Trennen jedes Wortes durch Unterstrich

Public void Sum_Negative_Number_As_1st_Param_Exception_Thrown() 

Public void Sum_Negative_Number_As_2nd_Param_Exception_Thrown () 

Public void Sum_Simple_Values_Calculated ()

Andere

• Beenden Sie Methodennamen mit Test
• Starten Sie Methodennamen mit dem Klassennamen

Ich bin ziemlich mit dir in diesem einen Mann. Die von Ihnen verwendeten Namenskonventionen sind:

• Klar, was jeder Testzustand ist.
• Spezifisch für das erwartete Verhalten.

Was brauchst du mehr von einem Testnamen?

Im Gegensatz zu Rays Antwort halte ich das Testpräfix nicht für notwendig. Es ist Testcode, das wissen wir. Wenn Sie dies tun müssen, um den Code zu identifizieren, haben Sie größere Probleme. Ihr Testcode sollte nicht mit Ihrem Produktionscode verwechselt werden.

Was die Länge und Verwendung des Unterstrichs betrifft , wen interessiert der Testcode? Nur Sie und Ihr Team werden es sehen, solange es lesbar und klar ist, was der Test tut. Machen Sie weiter! :) :)

Trotzdem bin ich noch ziemlich neu darin, meine Abenteuer damit zu testen und zu bloggen :)

Dies ist auch eine Lektüre wert: Strukturieren von Unit-Tests

Die Struktur hat eine Testklasse pro getesteter Klasse. Das ist nicht so ungewöhnlich. Was für mich jedoch ungewöhnlich war, war, dass er für jede getestete Methode eine verschachtelte Klasse hatte.

z.B

using Xunit;

public class TitleizerFacts
{
    public class TheTitleizerMethod
    {
        [Fact]
        public void NullName_ReturnsDefaultTitle()
        {
            // Test code
        }

        [Fact]
        public void Name_AppendsTitle()
        {
            // Test code
        }
    }

    public class TheKnightifyMethod
    {
        [Fact]
        public void NullName_ReturnsDefaultTitle()
        {
            // Test code
        }

        [Fact]
        public void MaleNames_AppendsSir()
        {
            // Test code
        }

        [Fact]
        public void FemaleNames_AppendsDame()
        {
            // Test code
        }
    }
}

Und hier ist warum:

Zum einen ist es eine gute Möglichkeit, die Tests organisiert zu halten. Alle Tests (oder Fakten) für eine Methode sind zusammengefasst. Wenn Sie beispielsweise die Tastenkombination STRG + M, STRG + O verwenden, um Methodenkörper zu reduzieren, können Sie Ihre Tests einfach scannen und wie eine Spezifikation für Ihren Code lesen.

Ich mag auch diesen Ansatz:

MethodName_StateUnderTest_ExpectedBehavior

Also vielleicht anpassen an:

StateUnderTest_ExpectedBehavior

Weil jeder Test bereits in einer verschachtelten Klasse ist

Ich neige dazu, die Konvention von MethodName_DoesWhat_WhenTheseConditionsso zu verwenden, zum Beispiel:

Sum_ThrowsException_WhenNegativeNumberAs1stParam

Was ich jedoch häufig sehe, ist, dass der Testname der Unit-Test-Struktur von folgt

• Ordnen
• Handlung
• Behaupten

Was auch der BDD / Gherkin-Syntax von folgt:

• Gegeben
• Wann
• Dann

Das wäre, den Test wie folgt zu benennen: UnderTheseTestConditions_WhenIDoThis_ThenIGetThis

Also zu deinem Beispiel:

WhenNegativeNumberAs1stParam_Sum_ThrowsAnException

Ich bevorzuge es jedoch, den zu testenden Methodennamen an die erste Stelle zu setzen, da die Tests dann alphabetisch angeordnet oder in der Dropdown-Box für Mitglieder in VisStudio alphabetisch sortiert angezeigt werden können und alle Tests für eine Methode zusammengefasst sind.

Auf jeden Fall mag ich es, die Hauptabschnitte des Testnamens im Gegensatz zu jedem Wort durch Unterstriche zu trennen , weil ich denke, dass es einfacher ist, den Punkt des Tests zu lesen und zu vermitteln.

Mit anderen Worten, ich mag: Sum_ThrowsException_WhenNegativeNumberAs1stParambesser als Sum_Throws_Exception_When_Negative_Number_As_1st_Param.

Ich benenne meine Testmethoden wie andere Methoden mit "PascalCasing" ohne Unterstriche oder Trennzeichen. Ich lasse den Postfix- Test für die Methode weg, weil er keinen Wert hinzufügt. Dass die Methode eine Testmethode ist, wird durch das Attribut TestMethod angezeigt .

[TestMethod]
public void CanCountAllItems() {
  // Test the total count of items in collection.
}

Aufgrund der Tatsache, dass jede Testklasse nur eine andere Klasse testen sollte, lasse ich den Namen der Klasse aus dem Methodennamen heraus. Der Name der Klasse, die die Testmethoden enthält, wird wie die zu testende Klasse mit dem Postfix "Tests" benannt.

[TestClass]
public class SuperCollectionTests(){
    // Any test methods that test the class SuperCollection
}

Für Methoden, die auf Ausnahmen oder Aktionen testen, die nicht möglich sind, stelle ich der Testmethode das Wort Cannot voran .

[TestMethod]
[ExpectedException(typeOf(ArgumentException))]
public void CannotAddSameObjectAgain() {
  // Cannot add the same object again to the collection.
}

Meine Namenskonvision basiert auf dem Artikel "TDD-Tipps: Testbenennungskonventionen und -richtlinien " von Bryan Cook. Ich fand diesen Artikel sehr hilfreich.

Der erste Satz von Namen ist für mich besser lesbar, da das CamelCasing Wörter trennt und die Unterbalken Teile des Namensschemas trennen.

Ich neige auch dazu, "Test" irgendwo aufzunehmen, entweder im Funktionsnamen oder im umschließenden Namespace oder in der Klasse.

Solange Sie einer einzelnen Übung folgen, spielt es keine Rolle. Im Allgemeinen schreibe ich einen einzelnen Komponententest für eine Methode, der alle Variationen einer Methode abdeckt (ich habe einfache Methoden;), und schreibe dann komplexere Testreihen für Methoden, die dies erfordern. Meine Namensstruktur ist daher normalerweise Test (ein Holdover von JUnit 3).

Ich verwende ein 'T'-Präfix für Test-Namespaces, Klassen und Methoden.

Ich versuche ordentlich zu sein und Ordner zu erstellen, die die Namespaces replizieren, dann einen Testordner oder ein separates Projekt für die Tests erstellen und die Produktionsstruktur für die Basistests replizieren:

AProj
   Objects
      AnObj
         AProp
   Misc
      Functions
         AFunc
   Tests
      TObjects
         TAnObj
            TAnObjsAreEqualUnderCondition
      TMisc
         TFunctions
            TFuncBehavesUnderCondition

Ich kann leicht erkennen, dass etwas ein Test ist. Ich weiß genau, um welchen Originalcode es sich handelt (wenn Sie das nicht herausfinden können, ist der Test sowieso zu kompliziert).

Es sieht genauso aus wie die Namenskonvention für Schnittstellen (ich meine, Sie werden nicht mit Dingen verwechselt, die mit 'I' beginnen, und Sie werden auch nicht mit 'T' beginnen).

Es ist einfach, mit oder ohne die Tests zu kompilieren.

Theoretisch ist es sowieso gut und funktioniert ziemlich gut für kleine Projekte.