Testy oprogramowania – Ola Kunysz – Notatka z nauki

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.