Jak testować? – Jakub Pilimon – Notatka z nauki

przez | 19 września, 2021
Jak testować: https://www.pexels.com/photo/businesspeople-with-pens-in-hands-examining-schemes-on-papers-5324974/

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łem o tym, jak testować: Testing: Love, Hate, Love Jakuba Pilimona.

Notatka z materiału o tym, jak testować: Testing: Love, Hate, Love:

Zanotowałem z tego materiału:

  • Strategie testowania:
    • Testy nigdy nie są robione
    • Testy psują się regularnie i są olewane przez zespół.
    • Testy wstrzymują deploye.
  • Jak testować:
    • Wypisz wszystkie możliwe scenariusze dla danego komponentu.
    • Przetestuj szczegóły implementacji, jeżeli są istotne.
    • Problem: Mała zmiana w kodzie może zepsuć wiele testów. Test sprawdzał za dużo.
      • Rozwiązanie: Robić testy sprawdzające decyzję i sprawdzające zachowania. I zrobić dwie klasy – jedna generuje zachowanie, a druga decyzję. Łatwiej będzie to testować.
    • Problem: Do kodu dodana została kolejna zależność. W testach brakuje nowej zależności.
      • Rozwiązanie: Tworzyć zależności w Setup.
    • Problem: Tworząc mocki zależności, trzeba znać szczegóły implementacji.
      • Rozwiązanie: Rozdzielić kod na: klasę:
        • mającą wiele zależności, ale nie podejmującą decyzji,
        • mającą mało zależności i podejmującą decyzję.
    • Problem: Jeżeli jest wiele czerwonych testów po zmianie w danej klasie, to nikt nie chce jej zmieniać.
      • Rozwiązanie: Bardzo możliwe, że ta klasa ma zbyt wiele odpowiedzialności (patrz Single Responsibility Principle).
    • Wyjątki:
      • Problem: Część programistów chce używać mocków w testach, a inni nie chcę.
      • Rozwiązanie: Klasy są różnego rodzaju. Dla jednych należy mockować, a dla drugich nie należy.
    • Jak testować, to z TDD:
      • TDD prowadzi do dobrego designu:
        • Dobre nazewnictwo.
        • Istnieje kontrakt.
        • Jest przetestowane.
        • Łatwo refaktoryzować.
      • Ale:
        • Pod spodem coraz bardziej możemy odbiegać od rzeczywistości.
      • Więc:
        • Musimy cały czas uważać na design i pogłębiać wiedzę na temat domeny. Ponieważ nie znając domeny TDD nie uchroni nas przed napisaniem złego oprogramowania.
    • Testy i TDD to (i programiści muszą to zrozumieć, zobaczyć i poczuć!):
      • Mniej bugów.
      • Lepszy kod.
      • Więcej zabawy.

Wszystkie posty związane z notatkami z nauki:

Źródła

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

Obraz główny

Materiał o tym, jak testować: Testing: Love, Hate, Love:

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *