Typowe wymogi pisania unit testów:
- Mają wykonywać się szybko
- Metodologia pisania oprogramowania: * Pisz unit test * uruchom testy * pisz małą zmianę * uruchom testy * refaktoryzuj * uruchom testy. Jeśli testy będą trwały więcej, jak kilka sekund max, to taka metodologia nie ma sensu
- Dlatego:
- Mają testować tylko pojedynczą metodę, a już na pewno nic więcej, jak klasę
- Wszystko inne ma być zamockowane
Piramida testów:
- Najwięcej unit testów, w drugiej kolejności testów integracyjnych, natomiast klikania ręcznie najmniej, jak to możliwe
- Trzymając się powyższej metodologii unit testów będzie cała hałda, i dobrze
Zadania testów:
- Walka z regresjami przede wszystkim
- Zmiana danej metody / klasy ma nie psuć jej specyfikacji w sposób niezamierzony
- Zmiana danej metody / klasy ma nie psuć innych, pozornie niezwiązanych klas w sposób niezamierzony
Unit testy wydają mi się przeczyć obu tym zadaniom?
- Unit testy nie chronią przed niezamierzonymi regresjami w obrębie metody / klasy, którą testują
- Jeśli kod danej metody / klasy ulega zmianie, to zmianie musi często ulec także jej unit test. Zatem stary unit test jest wyrzucony i nic nie testuje
- Unit testy nie chronią przed niezamierzonymi regresjami w innych miejscach kodu
- Jak mają chronić, skoro wszystkie inne klasy są zamockowane?
- Refaktoryzacja unieważnia unit testy
- Przeorganizowuję metody w klasie - muszę przepisać wszystkie / większość unit testów tych metod. Zmieniam publiczny interfejs klasy - muszę przepisać unit testy tego interfejsu. Stare testy są wyrzucone, więc nic nie testują i nie chronią przed regresjami w kodzie, który właśnie wprowadzam
Remedium: Tylko testy integracyjne / end to end?
- Tzw. „mądrzy ludzie” napisali piramidę testów, według której testów integracyjnych / e2e ma być wyraźnie mniej, niż unit testów - może mieli mądre ku temu powody?
- Testy integracyjne potrafią długo trwać - dokładne testowanie każdego elementu specyfikacji programu za ich pomocą wykluczy częste uruchamianie testów
- Testowanie działania głęboko zagnieżdżonych metodek za pomocą testów e2e może wymagać pisania skomplikowanych testów
- Już dokładne pisanie unit testów zajmuje b. dużo czasu, pisanie testów j.w. będzie zajmowało chyba nieakceptowalne ilości czasu
Naprawdę nie rozumiem?