Test jednostkowy nazewnictwo najlepszych praktyk [zamknięty]

Lubię stosować "powinien" Standard nazewnictwa dla testówpodczas nazywania urządzenia testowego po testowanej jednostce (tj. klasie).

Do zilustrowania (używając C# i NUnit):

[TestFixture]
public class BankAccountTests
{
  [Test]
  public void Should_Increase_Balance_When_Deposit_Is_Made()
  {
     var bankAccount = new BankAccount();
     bankAccount.Deposit(100);
     Assert.That(bankAccount.Balance, Is.EqualTo(100));
  }
}

Dlaczego "Powinno"?

Tak, pisanie" powinno " wszędzie robi się trochę powtarzalne, ale jak powiedziałem zmusza pisarzy do poprawnego myślenia (więc może być dobre dla nowicjuszy). Plus to generalnie skutkuje czytelną angielską nazwą testu.

Update :

Zauważyłem, że Jimmy Bogard jest również fanem 'should' I ma nawet bibliotekę testów jednostkowych o nazwie powinien.

Aktualizacja (4 lata później...)

Dla zainteresowanych, moje podejście do testów nazewniczych ewoluowało na przestrzeni lat. Jednym z problemów z powinien Wzór opisuję powyżej jako niełatwy do Poznania na pierwszy rzut oka, która metoda jest testowana. Dla OOP myślę, że bardziej sensowne jest rozpoczynanie nazwy testu od testowanej metody. Dla dobrze zaprojektowanej klasy powinno to skutkować czytelnymi nazwami metod testowych. Obecnie używam formatu podobnego do <method>_Should<expected>_When<condition>. Oczywiście w zależności od kontekstu możesz zastąpić czasowniki Should / When czymś bardziej odpowiednim. Przykład: Deposit_ShouldIncreaseBalance_WhenGivenPositiveValue()

Podoba mi się ten styl nazewnictwa:

OrdersShouldBeCreated();
OrdersWithNoProductsShouldFail();

I tak dalej. To naprawdę jasne dla nie-testera, na czym polega problem.

Kent Beck sugeruje:

• Jedno urządzenie testowe na 'jednostkę' (klasę programu). Oprawy testowe to same klasy. Nazwa urządzenia testowego powinna brzmieć:

  [name of your 'unit']Tests
  

• Przypadki testowe (metody urządzenia testowego) mają nazwy takie jak:

  test[feature being tested]
  

Na przykład, posiadający następującą klasę:

class Person {
    int calculateAge() { ... }

    // other methods and properties
}

Urządzenie testowe będzie:

class PersonTests {

    testAgeCalculationWithNoBirthDate() { ... }

    // or

    testCalculateAge() { ... }
}

Nazwy Klas . W przypadku nazw urządzeń testowych uważam, że "Test" jest dość powszechny w wszechobecnym języku wielu domen. Na przykład w domenie inżynierskiej: StressTest oraz w domenie kosmetycznej: SkinTest. Przepraszam, że nie zgadzam się z Kentem, ale używanie "Test" w moich oprawach testowych (StressTestTest?) jest mylące.

"jednostka" jest również często używana w domenach. Np. MeasurementUnit. Czy klasa o nazwie MeasurementUnitTest jest testem " Measurement "lub " MeasurementUnit"?

Dlatego lubię używać przedrostka " Qa " dla wszystkie moje zajęcia testowe. Np. QaSkinTest i QaMeasurementUnit. Nigdy nie jest mylony z obiektami domeny, a użycie prefiksu zamiast sufiksu oznacza, że wszystkie urządzenia testowe żyją razem wizualnie (przydatne, jeśli masz podróbki lub inne klasy wsparcia w projekcie testowym) {]}

Przestrzenie nazw . Pracuję w C# i przechowuję moje klasy testowe w tej samej przestrzeni nazw, co klasa, którą testują. Jest to wygodniejsze niż posiadanie osobnych testowych przestrzeni nazw. Oczywiście zajęcia testowe są w innym projekt.

Nazwa metody badania . Lubię nazywać moje metody, Gdyxxx_expectyyy. To sprawia, że warunek wstępny jest jasny i pomaga w automatycznej dokumentacji (a la TestDox). Jest to podobne do porad na blogu Google testing, ale z większym oddzieleniem warunków wstępnych i oczekiwań. Na przykład:

WhenDivisorIsNonZero_ExpectDivisionResult
WhenDivisorIsZero_ExpectError
WhenInventoryIsBelowOrderQty_ExpectBackOrder
WhenInventoryIsAboveOrderQty_ExpectReducedInventory

Zobacz: http://googletesting.blogspot.com/2007/02/tott-naming-unit-tests-responsibly.html

Jeśli chodzi o nazwy metod testowych, osobiście uważam, że używanie wyrazistych i udokumentowanych nazw jest bardzo przydatne(obok komentarzy Javadoc, które dodatkowo wyjaśniają, co robi test).

Ostatnio wymyśliłem następującą konwencję nazwania moich testów, ich klas i projektów w celu zmaksymalizowania ich opisów:

Powiedzmy, że testuję klasę Settingsw projekcie w MyApp.Serialization przestrzeń nazw.

Najpierw stworzę projekt testowy z MyApp.Serializacja.Testuje przestrzeń nazw.

W ramach tego projektu i oczywiście przestrzeni nazw stworzę klasę o nazwie IfSettings (zapisane jak IfSettings.cs).

Powiedzmy, że testuję metodę SaveStrings () . - >Nazwę test CanSaveStrings () .

Po uruchomieniu tego testu wyświetli się następujący nagłówek:

MyApp.Serializacja.Testy.IfSettings.CanSaveStrings

Myślę, że to mówi mi bardzo dobrze, co to jest testowanie.

Oczywiście dobrze jest, że w języku angielskim rzeczownik " Tests "jest taki sam jak czasownik"tests".

Nie ma ograniczeń dla Twojego kreatywność w nazewnictwie testów, dzięki czemu otrzymujemy dla nich pełne nagłówki zdań.

Zazwyczaj nazwy testowe będą musiały zaczynać się od czasownika.

Przykłady:

• wykrywa (np. DetectsInvalidUserInput)
• Throws (np. ThrowsOnNotFound)
W tym celu należy skontaktować się z Działem Obsługi Klienta.]}

Itd.

Inną opcją jest użycie "that "zamiast " if".

Ten ostatni ratuje mi jednak klawisze i opisuje więcej dokładnie to co robię, skoro Nie wiem, że testowane zachowanie jest obecne, ale testuję Jeśli tak.

[Edit ]

Po dłuższym używaniu powyższej konwencji nazw, odkryłem, że prefiks If może być mylący podczas pracy z interfejsami. Tak się składa, że Klasa testowa IfSerializer.cs wygląda bardzo podobnie do interfejsu ISerializer.cs w zakładce "otwórz pliki". Może to być bardzo irytujące podczas przełączania między testami, testowaną klasą i jej interfejsem. W rezultacie wybrałbym teraz That zamiast If jako prefiks.

Dodatkowo używam teraz-tylko dla metod w moich klasach testowych, ponieważ nie jest to uważane za najlepszą praktykę nigdzie indziej - " _ " do oddzielania słów w nazwach moich metod testowych jak w:

• [Test] public void detects_invalid_User_Input () *

Uważam, że jest to łatwiejsze do Czytaj.

[End Edit ]

Mam nadzieję, że zrodzi to więcej pomysłów, ponieważ uważam nazywanie testów za bardzo ważne, ponieważ może to zaoszczędzić dużo czasu, który w przeciwnym razie byłby poświęcony na zrozumienie, co robią testy (np. po wznowieniu projektu po dłuższej przerwie).

Używam pojęcia Given-When-Then . Spójrz na ten krótki artykuł http://cakebaker.42dh.com/2009/05/28/given-when-then / . artykuł opisuje to pojęcie w kategoriach BDD, ale można go używać również w TDD bez żadnych zmian.

Myślę, że jedną z najważniejszych rzeczy jest zachowanie spójności w konwencji nazewnictwa (i uzgodnienie jej z innymi członkami zespołu). Do wielu razy widzę mnóstwo różnych konwencji używanych w tym samym projekcie.

W VS + NUnit zazwyczaj tworzę foldery w moim projekcie, aby pogrupować testy funkcjonalne. Następnie tworzę klasy fixture unit test i nadaję im nazwę po typie funkcjonalności, którą testuję. Metody [Test] są nazwane według linii Can_add_user_to_domain:

- MyUnitTestProject   
  + FTPServerTests <- Folder
   + UserManagerTests <- Test Fixture Class
     - Can_add_user_to_domain  <- Test methods
     - Can_delete_user_from_domain
     - Can_reset_password

Powinienem dodać, że utrzymywanie testów w tym samym pakiecie, ale w katalogu równoległym do testowanego źródła eliminuje nadmiar kodu po przygotowaniu go do wdrożenia bez konieczności wykonywania kilku szablonów wykluczeń.

Osobiście lubię najlepsze praktyki opisane w "JUnit Pocket Guide" ... trudno pokonać książkę napisaną przez współautora Junita!

Nazwa przypadku testowego dla klasy Foo powinna brzmieć FooTestCase lub coś podobnego (FooIntegrationTestCase lub FooAcceptanceTestCase) - ponieważ jest to przypadek testowy. zobacz http://xunitpatterns.com/ dla niektórych standardowych konwencji nazewnictwa, takich jak test, przypadek testowy, urządzenie testowe, metoda testowa itp.