Jak nazywać testy (a jak nie)?

Dlaczego nazwy metod testów są tak istotne?

Ponieważ będziemy widzieć je o wiele częściej niż nazwy innych metod. 

Jednakowo z poziomu IDE, w raportach wykonanych testów na serwerze CI/CD, czy powiadomieniach e-mail/komunikatorów o nie przechodzących testach. 

Czytelność kodu wpływa na to, czy łatwo będzie powrócić do napisanego kodu po dłuższej przerwie. 

Konwencja, którą przyjmiesz, powinna ułatwić czytelność, nawigację w kodzie oraz mówić, jak dany test działa i co testuje. Bez zaglądania w implementację. 

Nazwy testów powinny być zrozumiałe dla każdego członka zespołu. 

Dotyczy to nawet tych osób, które nie programują: Scrum Master, Project Manager, Project Owner, UX designer czy tester manualny.

Jak nie nazywać testów?

Załóżmy, że mamy do napisania tylko 3 testy logowania dla poniższego panelu:

Mogą to być poniższe propozycje:

  • logowanie poprawnymi danymi
  • logowanie niepoprawnymi danymi
  • próba logowania bez podania hasła.
Zacznijmy od tego, jak NIE nazywać testów:
 
  • loginTest1
  • loginTest2
  • loginTest3

Takie nazwy testów są nieczytelne i nie mówią nam nic na temat tego, co dokładnie testują.

Nazwy testów powinny opisywać działanie testowanego komponentu, bez zgłębiania się w implementacje testów.

Właśnie dlatego nazwy testów są o wiele dłuższe od standardowych nazw metod.

Konwencja nazewnicza

Najpopularniejsza konwencja nazewnicza dla testów powstaje według wzoru:

NazwaTestowanejFunkcjonalności_OczekiwanyStan/DaneWejściowe_OczekiwanyWynik

Tak nazywałyby się nasze testy panelu logowania:

  • loginForm_WhenCredentialsAreCorrect_ShouldLogin
  • loginForm_WhenCredentialsAreIncorrect_ShouldAppearErrorMessage
  • loginForm_WhenOnlyEmailGiven_ShouldDisableLoginButton

Co jeszcze możesz zrobić, aby testy były bardziej czytelne?

Uzyć notacji snake_case zamiast camelCase. 

Notacja camelCase jest standardem w wielu językach np. w Javie, ale ciężko czyta się nazwy testów, które mają długą nazwę.

Jeśli użylibyśmy snake_case to nazwy testów wyglądałyby w ten sposób:

  • login_form_when_credentials_are_correct_should_login
  • login_form_when_credentials_are_incorrect_should_appear_error_message
  • login_form_when_only_email_given_should_disable_login_button

Nasze testy są już bardziej czytelne, ale możemy zrobić jeszcze kilka rzeczy… 

W tym konkretnym przypadku możemy usunąć nazwę testowanej funkcjonalności z nazwy testów. 
 
Natomiast testy z tej grupy przenieść do klasy testowej.
 
Teraz nazwy wyglądają tak:
 
  • when_credentials_are_correct_should_login
  • when_credentials_are_incorrect_should_appear_error_message
  • when_only_email_given_should_disable_login_button
Nazwy wyglądają coraz lepiej, ale co jeśli usuniemy słowo should i napiszemy nazwę testów tak, aby przypominały zdania, np. w ten sposób:
 
  • login_when_credentials_are_correct
  • appear_error_message_when_credentials_are_incorrect
  • disable_login_button_when_only_email_given
Teraz czytając nazwy testów wiemy, jak dana funkcjonalność działa, a nie jak powinna. Bez zgłębiania się w implementacje testów.
 
Co zyskaliśmy dzięki takiej konwencji nazewniczej:
 
  •  o wiele większą czytelność nazw
  • nazwy są zrozumiałe dla każdego członka zespołu
  • stworzyliśmy dokumentację o danej funkcjonalności.
Dokumentacja stworzona w ten sposób przypomina nam, jak działa dana funkcjonalność. 
 
Może być śmiało wykorzystana jako “transfer wiedzy” dla nowego pracownika.

 PODSUMOWANIE

Czy to jedyne słuszne rozwiązanie ? 

Nie. Możesz użyć innej konwencji i nie ma w tym nic złego. 
Ważne, żeby nazwy testów ułatwiały Ci pracę oraz przyspieszyły wdrożenie nowych pracowników w projekt.
 

W obecnych projektach dla klienta jednakowo dla API oraz E2E testów używamy notacji camelCase. 

 
Dla testów E2E używamy krótkich nazw testów, ale za to dodajemy opis testu w adnotacji @Desctription. Taka metodyka została użyta przy budowaniu projektów testowych i dlatego się jej trzymamy.
 

Nie jest to rozwiązanie idealne. 
Ma swoje minusy. 

W przypadku testów E2E opis jest widoczny dopiero po rozwinięciu wyniku testu w raporcie Allure’a. 
 
Opisy trzeba utrzymywać, jeśli zmienia się dana funkcjonalność, przez co łatwiej popełnić błąd. 
 
Przy zmianie całej funkcjonalności możesz zapomnieć zmienić opis w którymś ze zmienianych testów, przez co nie będzie aktualny. 

 

Przy używaniu konwencji  nazewniczej zaproponowanej powyżej nie będziemy mieli tego problemu.

Na koniec szybkie pytanie do Ciebie…
 
A jak wygląda konwencja nazewnicza w Twojej firmie? 
Koniecznie daj znać w komentarzu!

2 Comments

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *