Testy, jak dobrze testować?

0

Witam wszystkich
Tak sobie piszę różne rzeczy, piszę sobie do nich testy i wzięło mnie na trochę przemyśleń, żeby to poszerzyć swoją wiedzę. Liczę, że bardziej doświadczone osoby pomogą.

  1. Do tej pory wszystkie testy robiłem w PHPUnicie, czy powinienem poznać coś innego, aby robić to lepiej, czy PHPUnit jest wystarczający?
  2. Często mam tak, że klasa jest długa, zawiera wiele metod, które np. wywoływane są z jednej głównej. Jak podejść do testów? Robić dla każdej tej metody osobny test, czy też postarać się to wszystko przetestować w obrębie jednej metody na kilku przypadkach?
  3. Co powinienem testować dla danej metody? Na przykład działanie z dobrymi danymi jak i działanie z danymi które mają zwrócić błąd? Czy jeszcze jakieś inne wartości?
  4. Czy dana metoda powinna odpowiadać tylko za jeden test? To znaczy... Na przykład w każdej metodzie muszę stworzyć klasę aby wywołać jej metodę i przygotować jakieś dane. Czy poprawnym jest umieszczenie tego np. w metodzie setUp(), czy też każda funkcja powinna odpowiadać w całości za dany test? Słyszałem i takie i takie teorie, i sam nie wiem.
  5. Czasem mam sytuację, że nie mogę niczego przetestować, bo np. trzeba by gdzieś coś zmienić, zmockować itd. Powinienem zmieniać lekko kod pod testy, aby np. dać możliwość wprowadzenia jakiejś właściwości? Czy nie, czy testy mają być ściśle dostosowane do kodu?

To chyba wszystko z takich bieżących problemów. Będę wdzięczny za rady bardziej doświadczonych osób.
Pozdrawiam

0
  1. tak używa się phpunita
  2. zależy od stopnia skomplikowania kodu i tego ile masz czasu na to :)
  3. najlepsze testy to takie które pokryją kod w 100% czyli jak masz ifa to zrobisz test taki, ze się wykona if i piszesz drugi który sprawdzi działanie w else
  4. zależy od stylu całości projektu i stopnia skomplikowania kodu oraz ilości testów potrzebnych by pokryć 100% kod
  5. nie zawsze da się napisać pełne test np gdy sprawdzasz dane otrzymane z jakiegoś zewnętrznego serwisu, dlatego wtedy musisz robić mocki, a żeby robić mocki trzeba pisać odpowiednio kod czyli np korzystać z DI
0
  1. A coś jeszcze warto znać?
  2. Heh, a gdybym powiedział że czas mam nieograniczony to co? Projekty są dość małe, ostatnio miałem jedną dużą metodę wykonującą określone operacje wywołując mniejsze w tej samej klasie. I zastanawiałem się czy testować je wszystkie po kolei, czy tylko ogólnie tą zbiorczą.
  3. Rozumiem... Sporo ich w takim razie być powinno.
  4. A jak preferujesz? Jak polecasz? Teoretycznie użycie tego setUp nie powinno być problemem, po prostu ułatwiam i skracam zapis dając to co się powtarza w jednej metodzie. No ale właśnie też gdzieś słyszałem, że jedna metoda testu powinna robić całość od początku do końca, aby wykonać dany test i nie wiem sam.
  5. No właśnie, mam sobie API i jakiegoś clienta, który nie jest w DI i nie mam jak go podstawić. W takiej sytuacji powinienem myśleć o tym wcześniej i pisać tak, aby dało się wstrzykiwać mocki, czy po prostu odpuszczać takie miejsca?
0
  1. ja tylko z phpunita korzystam
  2. jak masz dużo czasu to piszesz test tak aby pokryć 100% - proste. Jeśli zbiorczo pokryjesz wszystko i jesteś w stanie znaleźć błąd jeśli się test wywali to można zbiorczo, osobiście w większości przypadków pisze tylko całościowe testy na endpointy, chyba, że rzeczywiście endpoint robi pod spodem sporo operacji jest podzielony na jakieś skomplikowane klasy no to wtedy takie klasy też trzeba potestować.
  3. a no sporo - jakieś 30-40% czasu poświęconego na samo programowanie to pisanie testów :)
  4. Nie używam setup, tworze swoje metody w klasie bazowej lub już w konkretnej klasie które nie są testem i je wykonuje tam gdzie potrzebuje
  5. powinieneś wcześniej przewidzieć, osobiście DI stosuje wszędzie
1
testyjak napisał(a):
  1. Często mam tak, że klasa jest długa, zawiera wiele metod, które np. wywoływane są z jednej głównej. Jak podejść do testów? Robić dla każdej tej metody osobny test, czy też postarać się to wszystko przetestować w obrębie jednej metody na kilku przypadkach?

To nie problem z testami tylko z klasą. Podziel tak, aby spełniała SRP, a potem testuj powstałe w ten sposób klasy.

  1. Co powinienem testować dla danej metody? Na przykład działanie z dobrymi danymi jak i działanie z danymi które mają zwrócić błąd? Czy jeszcze jakieś inne wartości?

Dobre, złe, przebiegi generujące wyjątki, i przypadki graniczne.
Nigdy nie myśl o osiąganiu żadnych procentów pokrycia kodu testem i uciekaj z każdego miejsca, w którym wynosi ono 100%. Zazwyczaj znaczy to, że ktoś napisał testy nie po to, aby faktycznie przetestować tylko po to, aby spełnić wymagania procentowe.

  1. Czy dana metoda powinna odpowiadać tylko za jeden test? To znaczy... Na przykład w każdej metodzie muszę stworzyć klasę aby wywołać jej metodę i przygotować jakieś dane. Czy poprawnym jest umieszczenie tego np. w metodzie setUp(), czy też każda funkcja powinna odpowiadać w całości za dany test? Słyszałem i takie i takie teorie, i sam nie wiem.

Część wspólną jak najbardziej umieszczaj w setupie - taka jego rola przygotowanie każdego testu w zestawie.

  1. Czasem mam sytuację, że nie mogę niczego przetestować, bo np. trzeba by gdzieś coś zmienić, zmockować itd. Powinienem zmieniać lekko kod pod testy, aby np. dać możliwość wprowadzenia jakiejś właściwości? Czy nie, czy testy mają być ściśle dostosowane do kodu?

Jeśli nie da się napisać testów bez zmieniania kodu, to znaczy, że kod został źle zaprojektowany i trzeba go poprawić.

0

Jak często się zdarza, że mimo przeprowadzonych testów apka/strona się wywala na produkcji ?

2

Jeśli ktoś testuje tylko jednostkowo i nigdy integracyjnie, to zawsze.

6

title

0

Dzięki za wszystkie odpowiedzi, to zawsze inne spojrzenie.

Wybaczcie jeśli to głupie pytanie ale... Czym się różnicą te testy jednostkowe od integracyjnych? Jak je pisać? Też PHPunita do nich używamy?

0

Zainteresuj się codeception. Uważam, że jest to fantastyczny framework (?), zwłaszcza dla początkujących, bo narzuca Ci pewne konwencje i nie musisz dumać pół dnia co, gdzie i jak. Napiszesz w nim każdy możliwy rodzaj testu: jednostkowy, integracyjny, funkcjonalny, akceptacyjny itd.

Sam niedawno zacząłem, więc odsyłam do mojego post'a na temat testowania: https://4programmers.net/Profile/72192/Microblog#entry-21239 Znajdziesz tam książki i materiały, z których korzystałem, żeby wprowadzić testy do swojego (legacy) projektu.

Kurs Laravela jest drogi, więc jeżeli nie masz z kim się zrzucić, albo nie ma wolnej gotówki, to myślę że ta cena już jest za wysoka, ja kupiłem trochę taniej.
Jeżeli chcesz wybrać to polecam najpierw książkę Feathers'a, a później Fowler'a.

Jak będziesz miał jakieś pytania (inne niż te, które można łatwo wygooglać) to chętnie pomogę.

0
somekind napisał(a):

Dobre, złe, przebiegi generujące wyjątki, i przypadki graniczne.
Nigdy nie myśl o osiąganiu żadnych procentów pokrycia kodu testem i uciekaj z każdego miejsca, w którym wynosi ono 100%. Zazwyczaj znaczy to, że ktoś napisał testy nie po to, aby faktycznie przetestować tylko po to, aby spełnić wymagania procentowe.

To znaczy że tego typu testy mam nie pisać IsArgumetnEmpty, IsParameterTypeOF, IsArgumentPassedToMethod, ArgumentNotNull, IsParameterExist. ??

Dlaczego nie mogę pisać testów typu Multi Case, Guard Case ?

0

@MrBean Bean: chyba nie rozumiem, co masz dokładnie na myśli. Testowanie pustych i nullowych parametrów zalicza się do złych albo generujących wyjątki dane. Nie rozumiem jak miałoby wyglądać takie coś jak IsArgumentPassedToMethod.

0

@Desu dzięki bardzo, chętnie się tym zainteresuję.

0

Panowie, a jeszcze co do samego PHPUnita - jak testujecie efekt na stronach? Po prostu CURLem? Czy jakimś Guzzle np.? Czy coś dedykowanego jest?
Bo robię małą aplikację bez frameworka i zacząłem się zastanawiać jak to przetestować... W Laravelu jest po prostu $this->get i samo to odpytuje stronę, nigdy nie sprawdzałem jak.

Podobne pytanie o bazę danych, jak ją testujecie, aby nie naśmiecić rekordów za każdym razem? Laravel ma traita chyba DatabaseTransaction i wszystko co się wykona po jego wykonaniu nie trafi do bazy. To dobra praktyka w ogóle? Jak to robić bez frameworka?

0

html możesz testować na różny sposób, html, który nie jest generowany przez js (a zakładam, ze o taki ci chodzi) możesz testować w laravelu, masz nawet metody na akcje wywoływane na froncie.

0

@mr_jaro no a co właśnie gdy nie mam Laravela tylko piszę coś mniejszego, bez frameworków? Próbować np. samym Guzzle albo zwykłym CURLem? Czy PHPUnit ma coś do tego o czym nie wiem?

0

No Guzzlem na pewno będzie Ci wygodniej. Przy okazji to jeden z najpopularniejszych klientów HTTP dla PHP.

1 użytkowników online, w tym zalogowanych: 0, gości: 1