O testowaniu dla programistów

Masz “prawdo jazdy” na pisanie testów. Co dalej?

Na swojej drodze do doskonalenia testów można zdobywać wiedzę na różne sposoby. Można czytać książki, oglądać prezentacje, kończyć kursy i zdobywać certyfikaty. Jednak najważniejsze jest to, co dzieje się później. Zdobycie wiedzy teoretycznej na temat testów i poprzestanie na tym jest jak zrobienie prawa jazdy i wrzucenie go do szuflady. Po jakim czasie zapomnisz, jak się jeździ?   Trening czyni mistrza! Nie tak dawno zdawałam egzamin na prawo jazdy kategorii A i odkryłam, że dokument prawa jazdy pozwala na rozpoczęcie nauki, a nie jej zakończenie. Podobnie jest z większością książek technicznych. Przykładowo czerwona książka do Scali (jedna z najlepszych jakie Read more…

By Ola Kunysz, ago

Jakich testów powinno być najwięcej?

Pewnie znasz piramidę testów. Według niej testów jednostkowych powinno być w projekcie najwięcej. Mniej powinno być integracyjnych, a najmniej end-to-end (e2e) ze względu na koszt tworzenia i utrzymania. Jest to dość logiczne podejście. Testy jednostkowe są tanie i proste. Dają bardzo szybką informację zwrotną. Można je też wykonywać lokalnie bez stawiania środowiska testowego, czy łączenia się z zewnętrznymi serwisami. Testy wyższego rzędu są nieco droższe i nie powinny być nadużywane. Czy to jest święta prawda każdego projektu?   Rysunek pochodzi z bloga Maćka Gajdzicy, który pisze o systemach embeded. Polecam jego artykuły i wystąpienia!!   Testy jednostkowe Testy jednostkowe sprawdzają odizolowaną funkcjonalność. Nie Read more…

By Ola Kunysz, ago

Im więcej testów, tym lepiej?

No to jakie jest to pokrycie kodu testami w Twoim projekcie? Wysokie / niskie? 95%, czy bardziej 40%? A może wystarczające? Tylko co to znaczy?   Jedna liczba W wielu projektach ustalany jest wymagany procent pokrycia kodu testami. Wynika to najczęściej z tego, że chcemy kogoś “zmusić” do pisania testów, więc tworzymy jakiś KPI (Key Performance Indicator). Ta liczba pojawia się w definition of done i teoretycznie możemy spać spokojnie. Jest tylko jeden problem. Nie określamy jakości tych testów. Kiepskie testy nie dają nam żadnej pewności przy pisaniu implementacji, czy refaktoryzowaniu kodu.     Żeby z ciekawości sprawdzić, jaki jest Read more…

By Ola Kunysz, ago

Założę się, że czasem używasz tych wymówek…

Nawet najlepszym programistom zdarzają się dni, w których pisanie testów wydaje się zbędnym narzutem pracy. Na pewno masz takie dni na swoim koncie. Zastanawiam się, jakich wymówek wtedy używasz. Może jednej z tych: 1. Trzeba szybko wypchnąć to na produkcję. Po co testować, skoro ma szansę zadziałać? Kiedy na produkcji pojawia się problem, albo kończy się sprint, pojawia się presja, żeby dowozić szybciej. Kierując się zasadą Pareta, uznajemy testy za najlepszych kandydatów do pominięcia. Prawda jest jednak taka, że właściwe testy są lepszym pomysłem, niż dobry design kodu. Wypuszczenie otestowanego kodu bez refaktoryzacji jest dużo bezpieczniejsze, niż najlepsza architektura bez testów. Read more…

By Ola Kunysz, ago

(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 Read more…

By Ola Kunysz, ago

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. Read more…

By Ola Kunysz, ago