Wybieranie nazw dla testów integracyjnych


13

Dzięki testom jednostkowym domena jest dość mała, więc jest łatwa. Użyłem methodName_conditions_result()schematu Osherove'a i okazało się, że jest to bardzo jasne.

Ale przy testach integracyjnych czuję, że miałoby to bardzo długą nazwę, a co mam na miejscu methodName? Jak nazwać klasy testów integracji?

Przykłady nazw testów integracyjnych w świecie rzeczywistym są bardzo mile widziane. Mam nadzieję, że odpowiedzi pomogą mi lepiej zrozumieć te testy.


1
dlaczego to pytanie zostało odrzucone (dwukrotnie)?
duże kamienie

Odpowiedzi:


6

Trochę inaczej podchodzę do testów jednostkowych i integracyjnych. Staram się nazywać je na podstawie funkcji w jak największym stopniu. Następnie, gdy wszystkie testy zakończą się pomyślnie, zobaczysz listę wszystkich funkcji, które działają i nie działają.

  • canRegisterUser
  • canHandleInvalidInput
  • canRelayDocumentBetweenServers
  • canCreateSchema
  • canLoginUsingWebService
  • canLoginUsingBasicAuth
  • canDeleteDocument
  • canAddDocument

Nazwanie testów w ten sposób nie zawsze jest pragmatyczne, ale może być bardzo pomocne, zwłaszcza po przeczytaniu setek testów jednostkowych i integracyjnych. Ogólnie obejmująca nazwa klasy, która zawiera te metody, powinna również wskazywać na testowane funkcje. Pomoże w organizacji.

Sugeruję również nazwać wszelkie testy jednostkowe dla poprawek błędów unikalnym prefiksem, bugfix1002aby udowodnić, że błąd został naprawiony.


5

Zostało to naprawdę napisane, aby pomóc w testach jednostkowych, ale być może okaże się, że te same zasady obowiązują (mniej więcej) w testach integracyjnych:

Sprawdź siedem kroków !

Preferuję to, że jakkolwiek to nazwiesz, tak naprawdę jest to nazwa zestawu testowego (nazwa urządzenia na naszej karcie), sprawdzany efekt oraz komunikat potwierdzający, który musi się wyróżnić i wyjaśnić przyczynę błędu. Jeśli uznasz, że jest to najłatwiejsze w przypadku nazewnictwa Asherove, z całego serca to popieram. Ale może sztuczka polega na tym, aby wypełnić część „metoda” tym, co ma sens, warunek, wynik i wyjątek.

Cieszę się, że widzę pakiet o nazwie „MakingADeposit” z testem o nazwie „AccountDoesntExist” i błędem „Oczekiwany wyjątek NonesuchAccount - nie otrzymano”.

Alternatywnie, jeśli nie przeszkadza mi oddzielenie nazwy pakietu testowego słowem „::”, nie mam nic przeciwko „AccountHandling :: MakingADeposit_AccountDoesntExist_ThrowsAnException”

Karta sugeruje również, że jeśli nie masz dobrego imienia, kontynuuj i podaj lepsze imię, gdy ci się pojawi (miejmy nadzieję, że przed przesłaniem kodu do CI).


2

Testy integracyjne powinny być zgodne z podobnymi zasadami jak testy jednostkowe, ponieważ każdy test powinien testować jeden aspekt wymagania, ale testuje system jako całość. Klasa powinna nazwać ogólną rzecz, która jest testowana, np. „TpcInputValidation”, a nazwa metody powinna wyraźnie odzwierciedlać to, co próbuje zrobić test, bez nadmiernego wysiłku, np. „ShouldRaiseValidationErrorWithBadDates ()”.

Metody powinny testować jedną koncepcję cechy, a duża liczba twierdzeń może wskazywać inaczej. (Ref. „Clean Code: A Handbook of Agile Software Craftmanship”, s. 132, autor Robert Martin).


Dlaczego uważasz, że „jedna cecha” zasadniczo oznacza „jedna cecha”? Wygląda na to, że chcesz stwierdzić, że system jest w stanie, w którym się spodziewasz, i może to być dowolna liczba twierdzeń. Ale dygresję, ponieważ pytanie dotyczy nazywania, a nie jak pisać test integracyjny.
Jeremy Heiler

@Andrew, nie powiedziałem, że to trudna zasada, ale obserwowanie liczby twierdzeń może pomóc w wytyczeniu testu koncepcji funkcji niekoniecznie jednej na metodę. Ograniczenie ich zakresu pomaga określić, gdzie występują problemy, gdy zawodzą. Ale dam ci, że nie jest wspaniale powiedzieć jedno twierdzenie i zredaguję to, dzięki.
Pod klucz

1

Problem w tym, że właściwa nazwa funkcjonalności jest zbyt długa dla nazwy metody? Wiem, że niezrozumiałe jest pisanie metod testowych o nazwach takich jak registerAndValidateUnderageUniversityDriverWithCoverageSetA_test()i może kiedykolwiek złamać reguły kompilatora dla długich nazw metod (PL / SQL dopuszcza tylko do 30 znaków - nie wiem, czy Java i C # nakładają takie krótkie nazwy, ale nawet jeśli tego nie zrobi, to dość nieporadnie przekroczy pewien punkt, a naprawdę długie nazwy metod mogą być przydatne tylko w przypadku generowanego kodu, który jest odczytywany / zarządzany przez inny generowany kod). Możesz spróbować go skrócić, regValUnderageUnivDrvrWCovrgA_test()ale to też jest naprawdę okropne do przeczytania. Jedną z opcji, z których nie lubiłem, ale była wtedy najlepszym wyboremunderageUnivDrvr_test_01()a następnie pojawił się arkusz kalkulacyjny odwzorowujący nazwy metod na znacznie dłuższy opis testowanej funkcjonalności. Brzydkie, ale zadziałało. Możesz również udokumentować opis testu w dokumentacji funkcji w pliku źródłowym, co może być przydatne, ponieważ możesz wygenerować dokumentację testów bezpośrednio z kodu, zamiast mapować tam iz powrotem między arkuszem kalkulacyjnym a kodem.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.