Was sind einige gängige Namenskonventionen für Unit Tests?

Question

Allgemein

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

Beispiele

1) Methodenname_StateUnderTest_ExpectedBehavior

Public void Sum_NegativeNumberAs1stParam_ExceptionThrown() 

Public void Sum_NegativeNumberAs2ndParam_ExceptionThrown () 

Public void Sum_simpleValues_Calculated ()

Quelle: Benennungsstandards für Unit Tests

2) Jedes Wort durch Unterstreichung 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
• Methodennamen mit Klassennamen beginnen

Answer 1

Ich stimme dir in diesem Punkt zu, Mann. Die Namenskonventionen, die Sie verwendet haben, sind:

• Klarheit über den jeweiligen Teststatus.
• Genaue Angaben über das erwartete Verhalten.

Was braucht man mehr für einen Testnamen?

Im Gegensatz zu Rays Antwort Ich glaube nicht, dass die Test Präfix notwendig ist. Es handelt sich um Testcode, das wissen wir. Wenn Sie dies tun müssen, um den Code zu identifizieren, dann haben Sie größere Probleme, Ihr Testcode sollte nicht mit Ihrem Produktionscode verwechselt werden.

Was die Länge und die Verwendung des Unterstrichs betrifft, so ist Testcode Wen kümmert das schon? Nur Sie und Ihr Team werden es sehen. Solange es lesbar ist und klar ist, was der Test tut, machen Sie weiter! :)

Allerdings bin ich noch recht neu im Testen und meine Abenteuer damit bloggen :)

Answer 2

Auch dies ist eine Lektüre wert: Strukturierung von Unit-Tests

Die Struktur hat eine Testklasse pro zu testender Klasse. Das ist nicht so ungewöhnlich. Ungewöhnlich war für mich jedoch, dass er für jede zu testende 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 der Grund dafür:

Nun, zum einen ist es eine gute Möglichkeit, Tests zu organisieren. Alle Tests (oder Fakten) für eine Methode werden in Gruppen zusammengefasst. Zum Beispiel, wenn Sie die Tastenkombination STRG+M, STRG+O verwenden, um die Methodenkörper zusammenzufassen, können Sie können Sie Ihre Tests leicht scannen und sie wie eine Spezifikation für Ihren Code lesen.

Auch dieser Ansatz gefällt mir:

MethodName_StateUnderTest_ExpectedBehavior

Stellen Sie sich also vielleicht darauf ein:

StateUnderTest_ExpectedBehavior

Da jeder Test bereits in einer verschachtelten Klasse enthalten ist

Answer 3

Ich neige dazu, die Konvention zu verwenden MethodName_DoesWhat_WhenTheseConditions so zum Beispiel:

Sum_ThrowsException_WhenNegativeNumberAs1stParam

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

• Vereinbaren Sie
• Gesetz
• Bestätigen Sie

Die auch die BDD / Gherkin-Syntax von folgt:

• Gegeben
• Wenn
• Dann

die darin bestehen würde, den Test in der Art von zu benennen: UnderTheseTestConditions_WhenIDoThis_ThenIGetThis

also zu Ihrem Beispiel:

WhenNegativeNumberAs1stParam_Sum_ThrowsAnException

Ich ziehe es jedoch vor, den Namen der getesteten Methode an die erste Stelle zu setzen, da die Tests dann alphabetisch geordnet werden können oder in der Dropdown-Box für Mitglieder in VisStudio alphabetisch sortiert erscheinen und alle Tests für eine Methode gruppiert werden.

---

Auf jeden Fall gefällt mir die Trennung der großen Abschnitte des Testnamens mit Unterstrichen, im Gegensatz zu jedem Wort weil ich denke, dass es das Lesen erleichtert und den Sinn des Tests besser vermittelt.

Mit anderen Worten: Ich mag: Sum_ThrowsException_WhenNegativeNumberAs1stParam besser als Sum_Throws_Exception_When_Negative_Number_As_1st_Param .

Answer 4

Ich benenne meine Testmethoden wie andere Methoden mit "PascalCasing" ohne Unterstriche oder Trennzeichen. Ich lasse das Postfix Test für die Methode out, da sie keinen Mehrwert bietet. Dass die Methode eine Testmethode ist, wird durch das Attribut TestMethode .

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

Da jede Testklasse nur eine andere Klasse testen soll, lasse ich den Namen der Klasse im Methodennamen weg. 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
}

Bei Methoden, die auf Ausnahmen oder Aktionen testen, die nicht möglich sind, stelle ich der Testmethode das Wort Kann nicht .

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

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

Answer 5

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

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