it-swarm.com.de

Was sind einige gängige Namenskonventionen für Komponententests?

Allgemeines

  • Befolgen Sie bei allen Tests die gleichen Standards.
  • Machen Sie sich klar, was jeder Teststatus 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: Benennungsstandards für Komponententests

2) Jedes Wort durch einen Unterstrich trennen

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 Klassennamen
202
stung

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

  • Machen Sie sich klar, was jeder Teststatus ist.
  • Spezifisch über das erwartete Verhalten.

Was brauchst du mehr von einem Testnamen?

Im Gegensatz zu Rays Antwort halte ich das Präfix Test 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 die Verwendung des Unterstrichs angeht, ist sein Testcode , wen zum Teufel interessiert das? Nur Sie und Ihr Team werden es sehen, solange es lesbar ist und klar ist, was der Test tut. Machen Sie weiter! :)

Das heißt, ich bin noch ziemlich neu im Testen und blogge meine Abenteuer damit :)

92
Rob Cooper

Dies ist auch eine Lektüre wert: Structuring 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, Tests zu organisieren. Alle Tests (oder Fakten) für eine Methode sind in Gruppen zusammengefasst. Wenn Sie beispielsweise die Tastenkombination STRG + M, STRG + O verwenden, um Methodenkörper zu minimieren, 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 einstellen auf:

StateUnderTest_ExpectedBehavior

Denn jeder Test wird bereits in einer verschachtelten Klasse sein

35
Robs

Ich neige dazu, die Konvention von MethodName_DoesWhat_WhenTheseConditions also 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 folgt:

  • Gegeben
  • Wann
  • Dann

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

so zu deinem beispiel:

WhenNegativeNumberAs1stParam_Sum_ThrowsAnException

Ich bevorzuge es jedoch, zuerst den Namen der zu testenden Methode anzugeben, da die Tests dann alphabetisch angeordnet oder in VisStudio im Dropdown-Feld für Mitglieder alphabetisch sortiert angezeigt werden können und alle Tests für eine Methode in Gruppen zusammengefasst sind.


In jedem Fall trenne ich den Hauptteil Abschnitte des Testnamens mit Unterstrichen, im Gegensatz zu jedem Wort, weil ich denke, dass dies das Lesen und Verstehen erleichtert des Tests über.

Mit anderen Worten, ich mag: Sum_ThrowsException_WhenNegativeNumberAs1stParam besser als Sum_Throws_Exception_When_Negative_Number_As_1st_Param.

26
CodingWithSpike

Ich benenne meine Testmethoden wie andere Methoden mit "PascalCasing" ohne Unterstriche oder Trennzeichen. Ich lasse den Postfix Test für die Methode aus, da er keinen Wert hinzufügt. Dass es sich bei der Methode um eine Testmethode handelt, 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 voran . Kann nicht .

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

Meine Namenskonvention basiert auf dem Artikel "TDD Tips: Test Naming Conventions & Guidelines" von Bryan Cook. Ich fand diesen Artikel sehr hilfreich.

22
Jehof

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

Ich neige auch dazu, "Test" irgendwo einzuschließen, entweder im Funktionsnamen oder im einschließenden Namespace oder der Klasse.

5
Frank Szczerba