![]() |
![]() ![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 340 Pomógł: 0 Dołączył: 28.09.2015 Ostrzeżenie: (0%) ![]() ![]() |
Witam serdecznie,
Uczę się pisania testów w Laravelu. Jako że nie wiem jak powinny wyglądać "profesjonalnie" - to chciałem dopytać czy to, co robię ma sens (IMG:style_emoticons/default/smile.gif) 1. Test 1 - test sprawdzający czy strona działa poprawnie
2. Test 2 - test logowania z dobrym i błędnym hasłem
3. Test 3 - test modułu reklam. Dodawanie nowej reklamy, sprawdzanie czy istnieje, pobieranie listy reklam, sprawdzanie czy walidacja pól działa, kasowanie
Czy takie testy są poprawne? Czy raczej powinny wyglądać inaczej?(IMG:style_emoticons/default/smile.gif) |
|
|
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 8 068 Pomógł: 1414 Dołączył: 26.10.2005 Ostrzeżenie: (0%) ![]() ![]() |
Takie testy są ok. Nazywają się testami Integracyjnymi lub akceptacyjnymi ( w zależności kto patrzy (IMG:style_emoticons/default/smile.gif) )
Generalnie tutaj testujesz czy funkcjonalność zadana w ogóle działa czyli zapisujesz i sprawdzasz czy się zrobił. Do tego możesz dołożyć testy Unit które będą testować wybraną klasę z logiką czyli np. masz klasę która generuje Ci coś a twoim zadaniem jest sprawdzić czy klasa będzie się zachowywała w najróżniejszych przypadkach czyli jak dasz dobre wartości to dobry wynik, jak dasz złe wartości to błąd, jak nie dasz wartości to błąd itd. |
|
|
![]()
Post
#3
|
|
Grupa: Zarejestrowani Postów: 821 Pomógł: 111 Dołączył: 11.09.2006 Skąd: Biała Podlaska Ostrzeżenie: (0%) ![]() ![]() |
Tak jak napisał kolega powyżej, testy są OK - ale można je napisać o wiele lepiej.
zamiast:
Tutaj widać, że budowanie URL leży:
Fakera nie musisz tworzyć za każdym razem, masz przecież trait'a którego możeszużyć:
|
|
|
![]()
Post
#4
|
|
Grupa: Zarejestrowani Postów: 340 Pomógł: 0 Dołączył: 28.09.2015 Ostrzeżenie: (0%) ![]() ![]() |
Tak jak napisał kolega powyżej, testy są OK - ale można je napisać o wiele lepiej.
zamiast:
Tutaj widać, że budowanie URL leży:
Fakera nie musisz tworzyć za każdym razem, masz przecież trait'a którego możeszużyć:
Dziękuję bardzo za uwagi / opinie (IMG:style_emoticons/default/smile.gif)
A jak taki test zapisać? (IMG:style_emoticons/default/smile.gif) Takie testy są ok. Nazywają się testami Integracyjnymi lub akceptacyjnymi ( w zależności kto patrzy (IMG:style_emoticons/default/smile.gif) ) Generalnie tutaj testujesz czy funkcjonalność zadana w ogóle działa czyli zapisujesz i sprawdzasz czy się zrobił. Do tego możesz dołożyć testy Unit które będą testować wybraną klasę z logiką czyli np. masz klasę która generuje Ci coś a twoim zadaniem jest sprawdzić czy klasa będzie się zachowywała w najróżniejszych przypadkach czyli jak dasz dobre wartości to dobry wynik, jak dasz złe wartości to błąd, jak nie dasz wartości to błąd itd. W firmach, które testy najczęściej się pisze? Pewnie te integracyjne? Unit testy idą do klas "nie laravelowych?" (IMG:style_emoticons/default/smile.gif) |
|
|
![]()
Post
#5
|
|
Grupa: Zarejestrowani Postów: 821 Pomógł: 111 Dołączył: 11.09.2006 Skąd: Biała Podlaska Ostrzeżenie: (0%) ![]() ![]() |
Z tego co zaobserwowałem, to w firmach rzadko kiedy piszę się testy (IMG:style_emoticons/default/wink.gif)
Unit: testy które testują daną klasę - tylko klasę, dajesz input do metody i sprawdzasz czy wynik jest spełnia Twoje oczekiwania, nie interesuje Cie za bardzo reszta. Feature: to testy które testują żądania do strony i oczekiwany response, czyli wysyłasz formularz, odbierasz błąd walidacji lub zwrócone dane. Następnie sprawdzasz czy zwrócone dane są zgodne z oczekiwaniami, sprawdzasz również status HTTP (w przypadku REST API - bardzo ważne) i inne rzeczy (z czasem sam ogarniesz, co testować a czego nie). Co jest bardzo przydatne moim zdaniem, to code coverage - puszczasz testy na całość, i pokazuje Ci miejsca których nie masz przetestowanych. Czyli żaden kod podczas wykonywania testów nie wszedł do danej instrukcji - czyli przewidziałeś pewną sytuację, ale nie przetestowałeś jej. Tak to wygląda w IDE: (IMG:https://snipboard.io/PifhS9.jpg) Linijka 45 nie została przetestowana, 44 i 48 już tak. Warto sobie po testować całe klasy (unit) wraz z kontrolerami (feature). Niektórych czasem nie ma sensu, ale to od programisty zależy. I oczywiście nie testujesz obcych paczek, tylko swój kod który napisałeś. Pisanie testów, owocuje w przyszłości, gdy zmienisz drobną rzecz, może się okazać że resposne się zmienił - testami to wychwycisz. Bez wychwycenia zmiany response, front może się posypać - czego nikt by nie chciał. No i zmiany commitujesz dopiero jak wszystkie testy są wykonane z sukcesem. Tutaj warto sobie dodać również automatyczne wykonywanie testów po przesłaniu zmian na GIT, więc nawet jak zapomnisz puścić testów lokalnie, to gitlab czy inny, poinformuje Cię o tym. Cytat A jak taki test zapisać? smile.gif Ja bym zapisał to tak, ale co programista to inny sposób - ja staram się używać, tego co mi podpowiada IDE.
|
|
|
![]()
Post
#6
|
|
Grupa: Zarejestrowani Postów: 2 707 Pomógł: 290 Dołączył: 16.12.2008 Skąd: Śląsk Ostrzeżenie: (0%) ![]() ![]() |
Tutaj parę ściąg, aby rozróżnić integracyjne od jednostkowych:
https://www.google.com/search?q=2+unit+test...off&tbm=vid (IMG:style_emoticons/default/smile.gif) Osobiście, ze względu na braki kadrowo/czasowe pisze głównie integracyjne, są one bardziej praktyczne, weryfikują działanie podobnie do testera manualnego, więc po prostu robią to co początkujący programista robi sam po jakimś update - przeklikuje system. |
|
|
![]() ![]() |
![]() |
Aktualny czas: 23.08.2025 - 07:54 |