W ramach rozwijania się oglądam i czytam różne materiały. Następnie wiedzę z nich umieszczam w Anki oraz w notatkach i uzupełniam własnymi przemyśleniami. Ostatnio zapoznałem się z materiałami omawiającymi testy oprogramowania Oli Kunysz.
Notatka z materiału przedstawiającego testy oprogramowania:
Zanotowałem z tego materiału:
- Uświadom sobie, że jeszcze wiele nie wiesz. Nigdy nie będziesz wiedział wszystkiego. Przygotuj się na ciągłą naukę, ale… niech Cię to nie zablokuje. Działaj i douczaj się cały czas. Podczas działania nauczysz się (i zapamiętasz) dużo więcej, niż podczas samej nauki.
- Szybko (szczególnie w zespole) przyznawaj się, że czegoś nie wiesz. Ktoś może Ci szybko pomóc i nauczyć Cię. Starając się znaleźć samemu rozwiązanie, możesz stracić wiele czasu.
- W projektach IT nie masz wpływu na wszystko. Wiele rzeczy będzie zrobione źle. Nie jesteś w stanie wszystkiego zrobić idealnie, a za jakiś czas idealny kod i tak stanie się przestarzały. Przyzwyczaj się i regularnie poprawiaj go. Starych rzeczy (budynków, aplikacji) nie burzy się i buduje od nowa, lecz cały czas modernizuje. Upiększaj go małymi krokami (patrz refaktoryzacja, kaizen i metoda skauta).
- Testy powinny być proste i czytelne. Testy są dokumentacją aplikacji (odzwierciedlają go idealnie i są zawsze aktualne (czerwony test mówi, że aplikacja tak nie działa)).
- Dobrze nazywaj rzeczy (zmienne, testy, obiekty, metody).
- Najpierw napisz testy, a dopiero później zacznij robić refaktoryzację.
- Pisząc testy, skup się na wymaganiach biznesowych, a nie na implementacji kodu, który testujesz.
- Nie mockuj wszystkiego.
- Nie kopiuj do testu logiki biznesowej.
- Zielone testy, jeżeli są złe, nie oznaczają, że kod produkcyjny jest dobry.
- Testy, tak samo jak kod produkcyjny, ewoluują z czasem. Dbaj o nie tak samo, jak o zwykły kod i tak samo często refaktoryzuj.
- TDD – Test Driven Development – tworzenie oprogramowania za pomocą kroków:
- Red – piszemy najprostszy test, którego nie przechodzi nasze oprogramowanie (bo jeszcze nie napisaliśmy oprogramowania), sprawdzający, czy wprowadzana funkcjonalność działa.
- Green – piszemy najprostszy kod produkcyjny, który sprawia, że test działa.
- Refactor – poprawiamy nasz kod tak, aby testy nadal działały.
- Interfejsów warto używać, aby:
- W testach zaślepiać szczegóły implementacji (np. wysłanie maila, dostęp do bazy danych, dostęp do zewnętrznego API).
- W testach interesować się wyłącznie zachowaniami (wynikami działań), a nie szczegółami działania.
- W jaki sposób wdrożyć w TDD w swoim zespole?
- Zacznij od siebie.
- Wymagaj od zespołu robienia testów (miary coverege, liczba testów).
- Rozmawiaj z zespołem.
- Rób szkolenia i warsztaty (np. TDD kata).
- Rób pair programming.
- Bądź otwarty na pomoc dla innych.
- Wprowadzaj TDD małymi krokami – nie wymagaj od razu perfekcji.
- Rób wspólne (zespołowe) pisanie nowej funkcjonalności z TDD (Coding Dojo, walka na kod – jedna osoba pisze rozwianie, a druga pisze test, który znajduje dziurę w rozwiązaniu).
- Zaślepki:
- Mock
- Stub
- Species
- Fake
- Dummy
- Code Coverege – miara mówiąca, jak bardzo kod pokryty jest testami. Nie mówi ona o jakości testów.
- Pozwala na znalezienie ścieżek, których nie przetestowaliśmy.
- Testy mutacyjne pomagają znaleźć obszary, których nie przetestowaliśmy.
- Nie pozwól, aby perfekcjonizm sprawił, że nic nie robisz (nie pokazujesz, nie sprzedajesz, nie publikujesz), bo Twoja praca nie jest jeszcze doskonała. Twoja praca nigdy nie będzie doskonała.
- Dobre testy (niezabetonowane, skupione na biznesowych wymaganiach, testujące to, co mają testować) dają pewność, że wprowadzona refaktoryzacja kodu nie wprowadza nowych bugów.
- Nie zaślepiaj wszystkiego, ponieważ będziesz testował mocki, a nie własny kod.
- Podczas refaktoryzacji testów / kodu, zmień czasem testy tak, aby jednak zrobiły się czerwony, bo czasem możesz zepsuć testy i nic one nie testują.
- Pisz testy jednostkowe i integracyjne. Nie możesz zaniedbać żadnego z nich.
- Każdy testy powinien:
- Mieć czytelną nazwę, po której wiadomo, co test testuje.
- Asercja powinna testować jedną rzecz (biznesową, to nie znaczy, że ma być dokładnie jedno Assert).
- Nie dawaj w nazwie testu And i nie sprawdzaj wielu rzeczy. Rozbijaj testy na pojedyncze scenariusze, jak najbardziej. Single Responsibility Principle.
Wszystkie posty związane z notatkami z nauki:
Źródła
Obraz główny
Materiały przedstawiające testy oprogramowania:
- Ola Kunysz vlog #2 – Wstyd się przyznać do niewiedzy?
- Ola Kunysz vlog #6 – Za co nie lubimy kodu legacy?
- PimpMyTests #1 – Test białej rękawiczki
- Jak poradzić sobie ze złymi testami? – Pimp My Tests #4
- Pimp My Tests #3 – Jak unikać betonowania kodu testami?
- Testy integracyjne a code coverage – Pimp My Tests #7
- Co zaślepiać, a czego nie zaślepiać w testach? – Pimp My Tests #5.mp4
- PimpMyTests #2 – Czy testy pomagają w refaktoryzacji?
- Ola Kunysz vlog #5 – Czy perfekcjonizm prowadzi do perfekcyjnych działań?
- Code coverage a testy mutacyjne – Pimp My Tests #6
- Lepsze testy – Mocki i Stuby
- Lepsze Testy – jak skutecznie wdrażać TDD w zespole?
- Lepsze testy – jak używać interfejsów?
- Testoranki #5