TDD Test Driven Development i Testy jednostkowe – Notatka z nauki

Zanotowałem z tego materiału:

• TDD  – Tworzenie oprogramowania sterowane testami (jednostkowymi):
  • Napisz najpierw jeden prosty test, a potem kod, który sprawi, że ten test będzie zielony.
  • Kroki TDD:
    • Red – Piszesz test sprawdzający wymaganie (jest on czerwony, bo nie masz jeszcze kodu implementującego to rozwiązanie).
    • Green – piszesz kod, który sprawia, że testy są zielone. Zaimplementuj go w sposób jak najprostszy i sprawiający, że wszystkie testy będą zielone.
    • Refactor – poprawiasz swój kod, aby był czytelniejszy i lepszy. Testy pozwalają zrobić to bezpiecznie – ciągle sprawdzają, czy wymagania są spełnione.
    • Przejdź do kolejnego wymagania – do kroku Red z testem kolejnego wymagania.
  • Na początku możesz napisać wiele testów – ale tylko nazwy tych testów, aby wyrzucić z głowy różne przypadki testowe. Zakomentuj te testy i zacznij TDD od najprostszego wymagania.
  • Testy powinny przedstawiać wszystkie wymagania związane z daną klasą.
• Testy jednostkowe nie powinny dotykać zewnętrznych rzeczy (np. bazy danych, serwisów). Należy je zamockować.
• Mockowanie to naśladowanie jakiegoś zachowania, np. pobieranie danych z bazy danych.
• Kod, który chcemy testować z użyciem mocków, musi:
  • Być luźno powiązany.
  • Opierać się na interfejsach.
• Każdy test powinien mieć tylko jedną assercje. Dzięki temu wiemy szybko, co takiego przestało działać. Implementację testu można zrobić w taki przypadku we współdzielonej metodzie. Z drugiej strony można też dodawać opisy do assercji – też będzie wiadomo, co się zepsuło – po konkretnym komunikacie o błędzie z assercji.