Jakie są popularne konwencje nazewnictwa dla testów jednostkowych? [Zamknięte]

Generał

• Przestrzegaj tych samych standardów dla wszystkich testów.
• Wyjaśnij jasno, jaki jest każdy stan testowy.
• Sprecyzuj spodziewane zachowanie.

Przykłady

1) MethodName_StateUnderTest_ExpectedBehavior

Public void Sum_NegativeNumberAs1stParam_ExceptionThrown() 

Public void Sum_NegativeNumberAs2ndParam_ExceptionThrown () 

Public void Sum_simpleValues_Calculated ()

Źródło: Standardy nazewnictwa dla testów jednostkowych

2) Rozdzielanie każdego słowa znakiem podkreślenia

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 ()

Inny

• Zakończ nazwy metod testem
• Zacznij nazwy metod od nazwy klasy

Jestem prawie z tobą w tym jednym człowieku. Użyte konwencje nazewnictwa to:

• Jasne informacje na temat każdego stanu testowego.
• Specyficzne dla oczekiwanego zachowania.

Czego więcej potrzebujesz od nazwy testu?

Wbrew odpowiedzi Raya nie sądzę, aby przedrostek testowy był konieczny. To kod testowy, wiemy o tym. Jeśli musisz to zrobić, aby zidentyfikować kod, masz większe problemy, kodu testowego nie należy mylić z kodem produkcyjnym.

Jeśli chodzi o długość i użycie znaku podkreślenia, jego kodu testowego , kogo to, do diabła, obchodzi? Tylko ty i twój zespół będziecie to widzieć, o ile będzie to czytelne i jasne o tym, co robi test, kontynuujcie! :)

To powiedziawszy, wciąż jestem całkiem nowy w testowaniu i blogowaniu moich przygód z nim :)

Warto również przeczytać: Testy jednostek strukturalnych

Struktura ma klasę testową dla każdej testowanej klasy. To nie jest takie niezwykłe. Ale dla mnie niezwykłe było to, że miał klasę zagnieżdżoną dla każdej testowanej metody.

na przykład

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
        }
    }
}

A oto dlaczego:

Po pierwsze, jest to dobry sposób na zorganizowanie testów. Wszystkie testy (lub fakty) dla metody są zgrupowane razem. Na przykład, jeśli używasz skrótu CTRL + M, CTRL + O, aby zwinąć ciała metody, możesz łatwo zeskanować testy i odczytać je jak specyfikację kodu.

Podoba mi się również to podejście:

MethodName_StateUnderTest_ExpectedBehavior

Więc może dostosuj się do:

StateUnderTest_ExpectedBehavior

Ponieważ każdy test będzie już w klasie zagnieżdżonej

Zazwyczaj używam konwencji MethodName_DoesWhat_WhenTheseConditions, na przykład:

Sum_ThrowsException_WhenNegativeNumberAs1stParam

Jednak często widzę, aby nazwa testu była zgodna ze strukturą testów jednostkowych

• Zorganizować
• działać
• Zapewniać

Który również jest zgodny ze składnią BDD / Gherkin:

• Dany
• Kiedy
• Następnie

który miałby nazwać test w następujący sposób: UnderTheseTestConditions_WhenIDoThis_ThenIGetThis

tak na twój przykład:

WhenNegativeNumberAs1stParam_Sum_ThrowsAnException

Jednak zdecydowanie wolę umieścić najpierw testowaną nazwę metody, ponieważ wtedy testy można ułożyć alfabetycznie lub posortować alfabetycznie w polu rozwijanym elementu w VisStudio, a wszystkie testy dla 1 metody są grupowane razem.

W każdym razie lubię oddzielać główne sekcje nazwy testu podkreślnikami, a nie każdym słowem , ponieważ uważam, że ułatwia to odczytanie i przejście do sedna testu.

Innymi słowy, lubię: Sum_ThrowsException_WhenNegativeNumberAs1stParamlepiej niż Sum_Throws_Exception_When_Negative_Number_As_1st_Param.

Nazywam swoje metody testowe tak jak inne metody przy użyciu „PascalCasing” bez podkreślników i separatorów. Opuszczam test Postfiksa dla tej metody, ponieważ nie dodaje ona żadnej wartości. O tym, że metoda jest metodą testową, wskazuje atrybut TestMethod .

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

Z uwagi na fakt, że każda klasa testowa powinna testować tylko jedną inną klasę, zostawiam nazwę klasy poza nazwą metody. Nazwa klasy zawierającej metody testowe nosi nazwę podobną do klasy testowanej z rozszerzeniem „Testy”.

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

W przypadku metod testujących wyjątki lub działania, które nie są możliwe, poprzedzam metodę testową słowem Nie można .

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

Moja konwencja nazywania oparta jest na artykule „Wskazówki TDD: Testowanie konwencji i wytycznych dotyczących nazewnictwa” Bryana Cooka. Uważam, że ten artykuł jest bardzo pomocny.

Pierwszy zestaw nazw jest dla mnie bardziej czytelny, ponieważ CamelCasing oddziela słowa, a podpórki oddzielają części schematu nazewnictwa.

Staram się także zawierać gdzieś „Test”, albo w nazwie funkcji, albo w otaczającej przestrzeni nazw lub klasie.

Tak długo, jak wykonasz jedną praktykę, tak naprawdę nie ma to znaczenia. Generalnie piszę pojedynczy test jednostkowy dla metody, która obejmuje wszystkie odmiany metody (mam proste metody;), a następnie piszę bardziej złożone zestawy testów dla metod, które tego wymagają. Moja struktura nazewnictwa jest więc zwykle testowa (relacja z JUnit 3).

Używam przedrostka „T” do testowych przestrzeni nazw, klas i metod.

Staram się być schludny i tworzę foldery, które replikują przestrzenie nazw, a następnie tworzę folder testów lub oddzielny projekt dla testów i replikuję strukturę produkcyjną dla podstawowych testów:

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

Z łatwością widzę, że coś jest testem, wiem dokładnie, do czego odnosi się oryginalny kod (jeśli nie możesz tego rozwiązać, test i tak jest zbyt skomplikowany).

Wygląda to tak samo, jak konwencja nazewnictwa interfejsów (tzn. Nie mylisz się z rzeczami zaczynającymi się od „ja”, ani z literą „T”).

Kompilacja z testami lub bez nich jest łatwa.

W każdym razie jest dobry w teorii i działa całkiem dobrze w przypadku małych projektów.