Nie lubię absurdalnych podziałów na różne rodzaje testów.
Ja mam wrażenie, że te podziały albo:
-
stosują zwykle początkujący, którzy szukają punktu zaczepiania (tudzież autorzy kursów/podręczników, którzy szukają trafnej metafory dzielącą wiedzę na kilka obszarów, stąd mamy podział na e2e, integracyjne, unitowe). Czyli generalnie taki podział, który się stosuje w celach edukacyjnych.
-
ludzie nieco bardziej zaawansowani stosują głównie po to, żeby z mądrą miną oddzielać rodzaj testów oraz po to, żeby trollować innych programistów i się kłócić z nimi o rodzaj testu (trochę jak w każdej dyskusji o Reakcie jako frameworku JS musi znaleźć się "this guy", który wyskoczy i powie React to nie framework bo mu XKCD 386 kazało, tak samo zawsze ktoś się będzie kłócił o to, jakiego rodzaju jest dany test.
Ew.
3. stosują ludzie, którzy po prostu potrzebują testować system na wielu poziomach, żeby sprawdzić poprawność działania aplikacji, dlatego roboczo wydzielają różne rodzaje testów, być może nawet stosują różne narzędzia (frameworki testowe, test runnery, headless browsers etc.) do testowania różnych rzeczy. Zapewne też trochę inną taktykę podejmują w przypadku różnych testów. Dlatego taki roboczy podział ma wtedy sens.
Co do 1. to Nie byłoby w tym nic złego, gdyby nie to, że złe rozumienie testów unitowych (czyli: piszemy testy do każdej klasy i metody) i rozpowszechniona opinia, że unit testy są "lepsze", prowadzi do pisania ogromnej ilości testów, które raz, że testują szczegóły implementacyjne (więc się rozwalą przy pierwszym refaktorze), dwa, że są kompletną stratą czasu, bo asercje są tak szczegółowe, że i tak nie powiedzą, czy apka działa, a jedynie to, czy implementacja pozostała taka sama.
To, co wielu ludzi uważa za testy unitowe, to raczej określa się snapshot tests (które nawiasem mówiąc można sobie wygenerować z automatu, jak ktoś chce - więc po co je pisać dodatkowo?).
A co do 2. to już jest przypadłość programistów (również moja), że coś nam każe mieć rację albo prostować to, co uważamy za błędy. Duty calls.
Punkt 3. niby oczywistość, ale mam wrażenie, że o testach więcej się mówi niż faktycznie się je pisze. A jeśli się je pisze to też ze złych powodów - z chęci bycia "profesjonalnym" albo z ambicji zdobycia 100% pokrycia kodu (co jest banalne do osiągnięcia swoją drogą), a nie z chęci przetestowania czy aplikacja dobrze działa i zapobieganiu regresji.