Testy oprogramowania – Ola Kunysz – Notatka z nauki

przez | 14 czerwca, 2021
Testy oprogramowania: https://www.pexels.com/photo/man-writing-on-table-3380743/

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

Bestseller dnia w księgarni Złote Myśli

Obraz główny

Materiały przedstawiające testy oprogramowania:

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Wymagane pola są oznaczone *