Ola Kunysz

Ola Kunysz

Ola Kunysz, programistka. Poza wytwarzaniem oprogramowania zajmuje się prowadzeniem szkoleń, pisaniem i szerzeniem wiedzy na temat jakości. Programowanie jest jej pasją. Od kilku lat jest słoikową wrocławianką, wcześniej mieszkała w Czarnej, Nowym Sączu i Chicago. Jest bardzo socjalnym stworzeniem, można ją znaleźć na Twitterze: https://twitter.com/OlaQnysz, LinkedInie, a nawet YouTube: https://www.youtube.com/c/olakunysz

Wszystkie artykuły autora

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ę.

Jak mierzyć jakość testów? Line coverage, branch coverage i testy mutacyjne

Do mierzenia jakości kodu stosujemy różne metryki, od złożoności (cyclomatic complexity), przez ilość błędów na produkcji, po dług techniczny (technical dept). Wiele zespołów dodało do tego również miarę pokrycia kodu testami (code coverage). Z tym podejściem wiąże się jednak ryzyko, że testy będą pisane głównie po to, żeby pokrywały więcej linijek kodu, a nie żeby dobrze chroniły przed regresją. To może oznaczać to samo, ale wcale nie musi.

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?

Jak zapewniać jakość, kiedy pracujesz zdalnie?

Wiele osób jest teraz zmuszonych do pracy zdalnej. To najczęściej jednak nie jest prawdziwa praca zdalna. Jeśli przełożeni podejrzewają, że cały Twój zespół właśnie gra w Wiedźmina albo ogląda Dom z papieru, to znaczy, że nie ma tutaj zaufania. Jeśli każą Wam się sto razy dziennie wdzwaniać na spotkania, albo wypełniać szczegółowe raporty, żeby temu zapobiec, to nie ma tutaj zaufania. A zaufanie jest niezbędne, jeśli chcesz pracować zdalnie, zwłaszcza asynchronicznie.