Jak testować? – Jakub Pilimon – Notatka z nauki

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.