Piszemy testy do open source – podsumowanie wyzwania

W ubiegłym tygodniu ponad 300 osób pisało testy i kod dla projektów open source oraz uczyło się dobrych praktyk. Pod okiem 7 mentorów i dwóch ekspertów domenowych spora grupa stawiała swoje pierwsze kroki w tym świecie.   Jak to się stało? Wszystko zaczęło się od pomysłu. Wystarczająco szalonego, żeby chciało się go robić i wystarczająco realnego, żeby ktokolwiek chciał do niego dołączyć. Kiedy przekułam pomysł w plan, napisałam do osób, które uważam za świetnych specjalistów i fajnych ludzi. To drugie jest równie ważne jak to pierwsze. Podczas wyzwania ludzie szybko się poddają, jeśli dostają w twarz jedynie „konstruktywną” informacją zwrotną. Czytaj dalej…

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.   Rok później Potem zmieniają się trendy, połowa zespołu odeszła do innych projektów, ktoś inny jest zainspirowany wystąpieniem na konferencji. Społeczność przestała się interesować zeszłorocznym skarbem i coraz mniej udziela się w tym temacie na StackOverflow. Co teraz?Macie dwie drogi. Albo znów rzucicie się na coś nowego ku zadowoleniu całego zespołu, albo Czytaj dalej…

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 Czytaj dalej…

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 Czytaj dalej…

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 Czytaj dalej…

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. Czytaj dalej…