Was sind einige beliebte Namenskonventionen für Komponententests?

Allgemeines

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

Beispiele

1) MethodName_StateUnderTest_ExpectedBehavior

Public void Sum_NegativeNumberAs1stParam_ExceptionThrown() 

Public void Sum_NegativeNumberAs2ndParam_ExceptionThrown() 

Public void Sum_simpleValues_Calculated ()

Source: Naming standards for Unit Tests

2) Trennen jedes Wort durch Unterstreichen

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

  • End method names with Test
  • Start method names with class name
0
hinzugefügt der Autor Wedge, Quelle

7 Antworten

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

  • Klären Sie, was jeder Testzustand ist.
  • Spezifisch über das erwartete Verhalten.

Was brauchen Sie mehr von einem Testnamen?

Contrary to Ray's answer I don't think the Test prefix is necessary. It's test code, we know that. If you need to do this to identify the code, then you have bigger problems, your test code should not be mixed up with your production code.

Wie für die Länge und Verwendung von Unterstreichung, seine Testcode , wer zum Teufel kümmert es? Nur du und dein Team werden es sehen, solange es lesbar ist und klar darüber ist, was der Test macht, mach weiter! :)

Das heißt, ich bin noch ziemlich neu zu testen und blogging meine Abenteuer damit

0
hinzugefügt
Ein zusätzliches Argument für das Präfix. Wenn Sie in der IDE nach einer Datei suchen, können Sie problemlos nach Testfällen suchen, indem Sie mit Test und Ihrem Klassennamen beginnen. Wenn der Klassenname und der Name der Testklasse gleich sind, müssen wir immer den Pfad zweier Dateien pausieren und lesen
hinzugefügt der Autor THIS USER NEEDS HELP, Quelle
Leichter Widerspruch "solange es lesbar und klar ist" und "wer ... kümmert sich". Nun, jeder kümmert sich darum, wenn es nicht lesbar und klar ist, deshalb ist es wichtig. :-)
hinzugefügt der Autor David Victor, Quelle

Ich benenne meine Testmethoden wie andere Methoden mit "PascalCasing" ohne Unterstriche oder Trennzeichen. Ich lasse den Postfix Test für die Methode aus, weil sie 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, setze ich der Testmethode das Wort Kann nicht voran.

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

My naming convension are base on the article "TDD Tips: Test Naming Conventions & Guidelines" of Bryan Cook. I found this article very helpful.

0
hinzugefügt
Ich mag es nicht, weil es nicht das erwartete Verhalten enthält
hinzugefügt der Autor Johannes Rudolph, Quelle
+1 für den Link zu meinem Post - obwohl es nicht notwendig ist, ein "Test" -Präfix in deinen Tests zu verwenden. Stellen Sie sicher, dass Ihre Tests das erwartete Verhalten angeben. Zum Beispiel CanRetrieveProperCountWhenAddingMultipleItems ()
hinzugefügt der Autor bryanbcook, Quelle

This is also worth a read: Structuring Unit Tests

Die Struktur hat eine Testklasse pro getesteter Klasse. Das ist nicht so ungewöhnlich. Aber was für mich 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:

Nun, zum einen ist es eine gute Möglichkeit, Tests organisiert zu halten. All die   Tests (oder Fakten) für eine Methode werden zusammengefasst. Zum Beispiel, wenn   Mit der Tastenkombination STRG + M, STRG + O können Sie Methodenverkörperungen zusammenfalten   scannen Sie einfach Ihre Tests und lesen Sie sie wie eine Spezifikation für Ihren Code.

Ich mag auch diesen Ansatz:

MethodName_StateUnderTest_ExpectedBehavior

Also vielleicht anpassen an:

StateUnderTest_ExpectedBehavior

Weil jeder Test bereits in einer geschachtelten Klasse ist

0
hinzugefügt
Für diejenigen, die den Reshaper-Test-Runner in Visual Studio verwenden, haben sie Fehler behoben, indem sie verschachtelte Test-Klassen in 8.x verwendet haben. Seitdem wurde dies meine bevorzugte Struktur bei weitem.
hinzugefügt der Autor angularsen, Quelle

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

Sum_ThrowsException_WhenNegativeNumberAs1stParam

Was ich jedoch sehe, ist, dass der Testname der Unit - Test - Struktur folgt

  • Vereinbaren
  • Handeln
  • Bestätigen

Dies folgt auch der BDD/Gherkin-Syntax von:

  • Gegeben
  • Wenn
  • Dann

which would be to name the test in the manner of: UnderTheseTestConditions_WhenIDoThis_ThenIGetThis

zu deinem Beispiel:

WhenNegativeNumberAs1stParam_Sum_ThrowsAnException

Allerdings bevorzuge ich es, zuerst den zu testenden Methodennamen zu setzen, da dann die Tests alphabetisch angeordnet werden können oder in der Dropdown-Box für Mitglieder in VisStudio alphabetisch sortiert angezeigt werden und alle Tests für eine Methode gruppiert werden.


In jedem Fall möchte ich die großen Abschnitte des Testnamens mit Unterstrichen trennen, im Gegensatz zu jedem Wort , weil ich denke, dass es einfacher ist, den Punkt zu lesen und zu bekommen des Tests über.

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

0
hinzugefügt

Solange du einer einzigen Übung folgst, ist es nicht wirklich wichtig. Im Allgemeinen schreibe ich einen einzelnen Komponententest für eine Methode, die alle Variationen für eine Methode abdeckt (ich habe einfache Methoden;) und schreibe dann komplexere Sätze von Tests für Methoden, die es erfordern. Meine Benennungsstruktur ist also in der Regel Test (ein Holdover von JUnit 3).

0
hinzugefügt

Die erste Gruppe von Namen ist für mich besser lesbar, da das CamelCasing Wörter trennt und die Unterstriche Teile des Benennungsschemas trennen.

Ich neige auch dazu, "Test" entweder in den Funktionsnamen oder den umschließenden Namespace oder die Klasse aufzunehmen.

0
hinzugefügt
@Frank methodName = camelCase Methodenname = PascalCase
hinzugefügt der Autor Metro Smurf, Quelle
@ metro-smurf: Interessanter Unterschied, ich habe noch nie den Begriff PascalCase gehört, und das mache ich schon lange. Ich sehe nur den Begriff PascalCase in Microsoft-Entwicklerkreisen, ist das was du tust?
hinzugefügt der Autor Frank Szczerba, Quelle
Geschichte um Pascal Casing und Camel Casing (aus: Brad Abrams - Blogs .msdn.com/brada/archive/2004/02/03/67024.aspx ) ... "Bei der anfänglichen Gestaltung des Frameworks hatten wir Hunderte von Stunden Debatte über Namensgebung. Um diese Debatten zu erleichtern, haben wir hat mit Anders Heilsberg (dem ursprünglichen Konstrukteur von Turbo Pascal) ein Schlüsselelement des Designteams geschaffen, und es ist daher nicht verwunderlich, dass wir Pascal Casing für den von der Programmiersprache Pascal
hinzugefügt der Autor Heliac, Quelle

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 sehen, dass etwas ein Test ist, ich weiß genau, zu welchem ​​Originalcode es gehört (wenn du das nicht durcharbeiten kannst, ist der Test sowieso zu kompliziert).

Es sieht genauso aus wie die Benennungskonvention der Schnittstellen, (ich meine, Sie werden nicht mit Dingen verwechselt, die mit "Ich" beginnen, und auch nicht mit "T").

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

Es ist in der Theorie sowieso gut und funktioniert ziemlich gut für kleine Projekte.

0
hinzugefügt
Zu ungarisch (Notation) für mich. Außerdem wird Präfix T für generische Typparameter verwendet.
hinzugefügt der Autor Danny Varod, Quelle
Ich stimme zu, die ungarische Notation wurde entzogen, und da der Konflikt mit standardmäßigen generischen Typparametern besteht, sehe ich in diesem Fall keine Ausnahme (wie es für Schnittstellen der Fall ist).
hinzugefügt der Autor SonOfPirate, Quelle
Interessanter Ansatz. Einige Leute mögen argumentieren, dass das T-Präfix Konflikte mit Konvention, die Sie in Generika verwenden (z. B. Funk (T1, T2, TResult)), aber ich persönlich ist es egal, solange es einen Konsens innerhalb des Teams gibt. Die Namen sind kurz, was die Dinge auch lesbarer macht.
hinzugefügt der Autor stung, Quelle