O testowaniu dla programistów

(Prawie) cała prawda o nazywaniu metod

Mówi się, że dwie najtrudniejsze rzeczy w programowaniu to: wygaszanie cache i dobieranie nazw. Trochę w tym prawdy. Są nawet tacy, którzy przyznają, że cache to jeszcze, ale te nazwy…   Jakie powinny być nazwy? No właśnie, jakie powinny być nazwy i co powinny mówić? Powinny mówić całą prawdę i tylko prawdę o tym, co dana metoda robi. Nie piszesz kodu dla siebie, tylko dla innych (i siebie w przyszłości). Nawet wujek Bob mówi o tym w Czystym Kodzie, że proporcje czytania kodu do pisania to 10 do 1. Jeśli metoda zwraca cenę produktu powiększoną o VAT, to wolisz, żeby Czytaj dalej…

Przez Ola Kunysz, temu

Krótka historia efektów ubocznych

Czy wiesz, w jakiej kolejności są odpalane Twoje testy? Ja nie wiem. Bo za każdym razem są uruchamiane w losowej kolejności. Takie działanie ma zapobiegać zależnościom między testami, ponieważ powinny onne działać niezależnie. Czasem nawet współbieżnie. Jeśli chcesz nadać wartości zmiennym, albo zainicjalizować klasę, powinno się to odbywać w metodach z adnotacjami @Before i @BeforeClass, a w JUnit 5 @BeforeEach i @BeforeAll. Taki układ zapewni Ci identyczny stan początkowy każdego testu i zapobiegnie dziwnym błędom. Jeśli masz coś do „posprzątania” po teście, użyj metody z adnotacją @After / @AfterEach. Jeśli sprzątanie dotyczy całej klasy testowej, należy użyć @AfterClass / @AfterAll. Czytaj dalej…

Przez Ola Kunysz, temu

Jeśli myślisz, że testy dają gwarancję bezbłędnej refaktoryzacji, to …

Jeśli myślisz, że testy dają gwarancję bezbłędnej refaktoryzacji, to trochę masz rację, ale też trochę nie masz 🙂 Im lepsza baza testów, tym szansa na wykrycie regresji będzie wyższa. Nie gwarantuje to jednak, że w każdym przypadku kod będzie działał zgodnie z pierwotnymi wytycznymi. Refaktoryzacja polega na zmianie implementacji bez zmian w funkcjonowaniu aplikacji i nie zawsze jest łatwym zadaniem. Sytuacja może być tym trudniejsza, im mniej znasz wymagania biznesowe. Kiedy nie bierzesz udziału w procesie planowania i podejmowania decyzji, znasz tylko to, co zostało spisane w formie testów lub kodu.Słyszałam ostatnio świetną historię, którą opowiadałam już podczas mojej prezentacji Czytaj dalej…

Przez Ola Kunysz, temu

Zanim zaczniesz się zastanawiać jak przetestować prywatną metodę…

Pewnie chociaż raz zdażyło Ci się wyszukiwać frazę „jak przetestować metodę prywatną?”. Wiadomo, że to jest możliwe i czasem wydaje się dość rozsądne. Czasem nie ma wyjścia i musisz to zrobić. Zanim jednak podejmiesz to wyzwanie, zadaj sobie te trzy pytania: 1. Czy można przetestować logikę używając wyłącznie publicznych metod? Metody prywatne powinny służyć zwiększaniu czytelności kodu i wyciąganiu małych części wspólnych. To nie miejsce na ważne operacje i rozpisywanie strategii działania. Jeśli Twoja metoda przykładowo dodaje VAT do ceny, może wystarczy sprawdzić, czy cena brutto jest ok? Albo jeśli skleja tekst, wystarczy porównać efekt końcowy zwracany przez publiczną metodę Czytaj dalej…

Przez Ola Kunysz, temu

Czy naprawdę używasz Mocków?

Do naszego żargonu na stałe weszło słowo mockowanie, głównie jako pochodna używania biblioteki Mockito. O każdym zaślepionym obiekcie mówimy, że jest mockiem, ale czy to jest poprawna nazwa? Nie wiem jak Ty, ale ja tak naprawdę bardzo rzadko używam mocków. Używam głównie Stubów. Stub to właśnie taka zaślepka, która zwraca konkretną wartość przy wywołaniu metody. Różnice między Mockami i Stubami tłumaczyłam podczas mojego webinaru. Niektóre biblioteki, jak Mockito niestety nie rozróżniają różnych typów zaślepek. Do czego więc służą mocki? Do sprawdzania implementacji. Możesz sprawdzić nie tylko parametry, z którymi została wywołana metoda, ale też ilość wywołań. Masz do wyboru kilka rodzajów Czytaj dalej…

Przez Ola Kunysz, temu