#kod

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

Na swojej drodze do doskonalenia testów wiedzę można zdobywać 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?

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 one działać niezależnie. Czasem nawet współbieżnie.

Jaki jest koszt programistycznych decyzji?

Poznajesz nową bibliotekę, nowy framework, uczysz się nowego podejścia do architektury. Wydaje się, że będzie pasować do Twojego projektu. Przekonujesz zespół, namawiasz "biznes" i wprowadzacie to z sukcesem na produkcję. Leje się szampan, klepiecie się plecach. Dla takich dni warto było przewalać ten cały kod legacy przez lata.

Czy znajdziesz minutkę, żeby porozmawiać o TDD?

Kiedy zaczynam rozmawiać o TDD (Test Driven Development), przeważnie spotykam się z dwoma reakcjami. Albo ktoś jest bardzo podekscytowany, albo reaguje agresywnie. To jest chyba jeden z tych tematów, które dzielą branżę na pół. Chociaż nigdy nie przekonuję nikogo, że to jest lek na całe zło. Nic nawet nie obiecuję, ale czasem czuję się jak sprzedawca odkurzaczy.

Czy wiesz, jacy są czterej wrogowie pracy z kodem legacy?

Pewnie masz na swoim koncie pracę z cudzym kodem. Rzadko zdarza się pracować wyłącznie w projektach Greenfield, gdzie można napisać wszystko po swojemu...

Piszesz testy do wymagań biznesowych, czy do implementacji?

Zastanawiasz się czasem, po co piszesz testy? Poza tym, że tak trzeba, albo tak każą... Piszesz testy, żeby sprawdzić, czy kod działa, czy żeby udowodnić, że działa? Czy testy opierają się o wymagania biznesowe, czy o implementację? Poza dopisywaniem testów do odziedziczonego kodu powinniśmy się raczej kierować wymaganiami, niż naszą interpretacją, nie uważasz?

Czy jakość kodu jest równoważna jakości projektu?

Pewnie lubisz pisać dobry kod? Zakładam, że skoro czytasz tego bloga, to temat jakości jest Ci bliski. Bardzo mnie to cieszy! Jakość projektu to nasza wspólna sprawa. Tylko czy my zawsze mówimy o tym samym? Czy wysoka jakość dla programistów, testerów, managerów to to samo, co dla klienta? Jeśli tak myślisz, to trochę Cię rozczaruję.

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?

Przegląd testerskiego Internetu 2022.12.09

Wracamy z naszym cyklicznym przeglądem testerskich (i nie tylko) nowinek.

Programista musi testować

Testy jednostkowe, integracyjne i end-to-end to jedne z podstawowych metod kontroli jakości, którymi muszą się posługiwać również osoby, które tworzą kod.