Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Test-Driven Development

Test-Driven Development

6240b79bc4a4f3b60c404f74a5e87ff8?s=128

Kamil Kowalski

June 19, 2020
Tweet

Transcript

  1. TEST-DRIVEN DEVELOPMENT KAMIL KOWALSKI kamil.k.kowalski@gmail.com

  2. CZYM NIE JEST TDD? • TDD nie oznacza testowania! •

    TDD to nie testy jednostkowe! • TDD nie jest magiczną receptą (na wszelkie bolączki projektu)! • TDD to nie narzędzia!
  3. CZYM JEST TDD? • TDD to process wytwarzania oprogramowania w

    którym kluczową rolę odgrywają: • Wymagania – określone przez Product Owner’a • Zwinna organizacja zespołu • Krótkie iteracje • Prostota architektury • Czysty kod aplikacji • Testy jednostkowe • Ciągła integracja
  4. CZYM JEST TDD? • W TDD programiści projektują / piszą

    : • Testy jednostkowe • Architeturę / kod aplikacji • Aby dobrze zprojektować testy oraz aplikację, potrzebne są jasno określone wymagania • Testy powstają w pierwszej kolejności – przed kodem aplikacji • Zmusza to programistów do myślania o aplikacji nie tylko w kontekście twórcy ale także użytkownika • Testy sterują / wymuszają sposób pisania kodu • “Do the simplest thing that could possibly work” • Mniejsze pole manewru jak napisać daną funkcjonalność
  5. TDD - ZALETY • Dokładnie zrozumienie wymagań – testy piszemy

    z uwzględnieniem wymagań • Szybka weryfikacja działania kodu aplikacji – czy kod dalej działa poprawnie • Lepsza architektura aplikacji • Pisanie dobrych testów wymaga odpowiedniej budowy aplikacji • Prostsze i bezpieczniejsze poprawianie kodu • Testy jako aktualna dokumentacja kodu • Mniejsza ilość ręcznego debugowania kodu i wyszukiwania błędów • Lepsze zarządzanie kodu w czasie • Krótszy całkowity czas procesu wytwarzania aplikacji • Mniejsza liczba błędów występująca w późniejszych etapach życia aplikacji
  6. TDD - WADY • Wysoki „próg wejścia” • W początkowej

    fazie spory spadek wydajności wytwarzania nowych funkcjonalności • Na ogół konieczność nauczenia dużej liczby nowych zagadnień • Pisanie testów jednostkowych • Wzorce projektowe i architektura aplikacji • Poznanie nowych narzędzi • Zmiana sposobu myślenia • Brak zrozumienia u menadżerów • Opory przez wdrożeniem TDD – często słuszne
  7. ORGANIZACJA PROJEKTU • Ważnym aspektem procesu TDD jest zespół zorganizowany

    w sposób zwinny • Proces • Scrum • Kanban • Kluczowe osoby: • Product Owner • Scrum master / menadżer zespołu • Team leader • Narzędzia: • Dashboard • JIRA, Redmine, etc.
  8. ARCHITEKTURA APLIKACJI • Aby aplikcja mogła być wytwarzana w TDD

    potrzebna jest odpowiednia architektura – tzw. clean architecture • Aplikacja nie może być „monolitem” – musi być podzielona na moduły • Podstawowe wzorce: • IoC – Inversion of Control (odwrócenie sterowania) • Depedency Injection (wstrzykiwanie zależności) • MicroServices (mikro usługi) • Niezależne referencje • nuget, maven, CocoaPods, etc… • Podstawowe zasady: • YAGNI - You Aren’t Going to Need It • KISS - Keep It Simple Stupid • DRY – Don’t Repeat Yourself
  9. PRACA Z KODEM • Always code as if the guy

    who ends up maintaining your code will be a violent psychopath who knows where you live. • Poprawne testy jednostkowe wymagają na ogół wykorzystania wzorców projektowych • Podstawowa reguła SOLID • Single responsibility • Open-close • Liskov substitution • Interface segregation • Dependency inversion
  10. PRACA Z KODEM • Code Smells – „smród w kodzie”

    • Zdublowany kod, długie metody, duże klasy, długa lista parametów, switch, „magiczne numery”, skomplikowane warunki, nieużwany kod • Code style – styl programowania • DoD – Definition of Done • Code review • Coding dojo • Wysokiej jakości kod jest: • Łatwy do przeczytania i zrozumienia • Trudno w nim ukryć błędy logiczne • Łatwy do rozszerzenia • Łatwy do zmiany
  11. TESTOWANIE • Proces związany z wytwarzaniem oprogramowania • Weryfikuje poprawność

    działania aplikacji • Czy aplikacja nie zawiera błędów • Czy działa zgodnie z wymaganiami • Dwa sposoby testowania aplikacji: • Ręczny – na ogół testerzy • Automatyczny • Rodzaje testów • Jednostkowe • Integracyjne • Interfejsu użytkownika • Akceptacyjne
  12. TESTOWANIE • Testowanie jednostkowe • Automatyczny fragment kodu testujący pojedynczą

    czynność (efekt wykonania) • Testowany element jest odizolowany od reszty systemu • Wszystkie zależności to atrapy z oczekiwanym zachowaniem • Testowanie integracyjne • Wykonywane są w celu wykrycia błędów w interakcji między poszczególnymi elementami systemu • Sprawdzają czy jeden obiekt wysłał do drugiego obiektu dane w odpowiedni osób i czy obiekt to zrozumiał • Na ogół są dużo bardziej skomplikowane od testów jednostkowych • Pisanie testów jest dłuższe oraz ich czas wykonywania
  13. TESTOWANIE • Testy interfejsu użytkownika • Polegają na sprawdzeniu czy

    wszystkie elementu w testowanej aplikacji są wyświetlane poprawnie • Na ogół automatyczne • Testowane są głównie podstawowe funkcjonalności aplikacji • Dość kosztowne w utrzymaniu i zarządzaniu • Testy akceptacjne • Służą do uzyskania formalnego potwierdzenia wykonania oprogramowania spełniającego określone założenia • Wymagania funkcjonalne oraz niefunkcjonalne • Na ogół nie służą do wykrywania błędów w aplikacji
  14. TESTOWANIE • Jakie testy są najlepsze? • Wszystkie razem!! •

    Wszystkie rodzaje testów testują różne aspekty systemu oraz uzupełniają się nawzajem • Na ogół najprościej wdrożyć testy jednostkowe • Są najprostsze i najłatwiej jest nimi zarządzać • Należy pamiętać, że same testy jednostkowe nie gwarantują nam poprawności działania aplikacji
  15. TEST JEDNOSTKOWY - CECHY • Automatyczny oraz powtarzalny • Test

    zawsze musi dać ten sam wynik (nie zależnie od działania innych testów) • Testuje w izolacji obiekt • Jeden test to jeden scenariusz • Np.: Czy metoda sprawdziła, czy istnieje dany użytkownik • Prosty w budowanie – testy pisze się szybko • Czytelny • Bardzo często służą jako dokumentacja
  16. TEST JEDNOSTKOWY - CECHY • Czas działania testu jest krótki

    • System na ogół zawiera setki/tysiące testów, które powinny wykonywać się maksymalnie kilka minut • Łatwy w zarządzaniu • Gdy test się nie powiedzie – powinniśmy w prosty sposób wiedzieć czemu tak się stało
  17. TEST JEDNOSTKOWY - RODZAJE • Testy jednostkowe można podzielić na

    trzy rodzaje: • Sprawdzające wynik działania • Np.: czy metoda zwróciła określoną wartość • Sprawdzające stan obiektu • Np.: czy po wykonaniu metody ustawiona jest odpowiednia właściwość • Integracje między obiektami • Np.: czy obiekt wywołał inny obiekt • Wykorzystywanie atrap (mock’ów)
  18. CYKL PRACY W TDD Praca programisty TDD (proces wytwarzania oprogramowania)

    jest podzielony na trzy etapy: • Pisanie testu jednostkowego, który nie przechodzi (etap red) • Implementacja funkcjonalności, które poprawia test (etap green) • Refaktoryzacja kodu – usuwamy duplikację kodu oraz poprawiamy desing aplikacji • Testy pilnują, czy nie wprowadziliśmy błędów w działaniu kodu
  19. RED, GREEN, REFACTOR Nowe wymaganie Nowy test Wykonaj testy Nowy

    kod Wykonaj testy Refactor Wykonaj testy Make it Fail Make it Work Make it Better Nowy kod powstaje tylko po nieprzechodzącym teście Tak prosto jak to tylko możliwe
  20. CIĄGŁA INTEGRACJA • Continuous integration metoda pozwalająca na bieżąco śledzić

    status projektu • Repozytorium kodu: GIT, SVN, Team Foundation, ... • Serwer CI: Hudson, Jenkins, CC.NET, TeamCity, ... • Narzędzia metryk: • Styl kodowania – Style Cop • Pokrycie testami (code coverage) – Ncover, dotCover • Złożoność cyklomatyczna (cyclomatic complexity) - NDepend • Pisząc w TDD musisz wrzucać kod do repozytorium kilka razy dziennie!