Ten wpis jest prostą odpowiedzią po to, żeby nie zgodzić się w kilku kwestiach. Ale muszę to powiedzieć: bardziej zgadzam się, niż nie zgadzam.
DHH przedstawia siedem punktów. Powtórzyłem je poniżej razem z moimi komentarzami. A ponieważ DHH nie uzasadnia swoich opinii, więc ja nie będę uzasadniał moich.
Poniższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :
http://blog.cleancoder.com/uncle-bob/2017/03/06/TestingLikeTheTSA.html
Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.
1. Nie celuj w 100% pokrycia kodu testami.
Nie zgadzam się. Celuj najwyżej jak się da. Traktuj 100% jak asymptotyczny cel. Żadna inna liczba nie jest bardziej rozsądnym celem. Nie ma dobrego powodu, żeby przestać podbijać procent pokrycia wyżej.
2.Stosunek kodu produkcyjnego do kodu testowego powyżej 1:2 to zapaszek, a powyżej 1:3 to smród.
Nie zgadzam się. Stosunek 1:1 linii kodu jest na oko właściwy. Jeżeli masz 20 tys. linii kodu produkcyjnego, to prawdopodobnie powinieneś mieć około 20 tys. linii kodu testowego. (Tak na marginesie, nie rozumiem toku rozumowania DHH w zakresie tych stosunków. Myślę, że miał na myśli, w pierwszym przypadku coś około 2:1, a w drugim przypadku, to miało być coś w rodzaju 1,5:1. A może to ja jestem po prostu nieogarnięty.)
3. Prawdopodobnie robisz to źle, jeżeli testowanie zabiera Ci więcej niż 1/3 Twojego czasu. Zdecydowanie robisz to źle, jeżeli testowanie zabiera Ci więcej niż połowę czasu.
Zgadzam się. Testowanie nie powinno zabierać Ci żadnego czasu. Pisanie testów, szczególnie TDD, wymaga czasu ujemnego (co oszczędza ogromną ilość czasu). Każdy niewarty uwagi test, którego nie napiszesz, kosztuje Cię czas.
4. Nie testuj standardowych połączeń, walidacji, zakresów z Active Record.
Zgadzam się. Zasadniczo nie ma powodu, żeby testować swój framework; tak długo, jak długo mu ufasz. Jeżeli mu nie ufasz (i jest bardzo wiele frameworków, które nie są godne zaufania) wtedy pisanie testów sprawdzających framework może mieć sens. Traktuj to jako "Inspekcję z Sanepidu".
5. Zostaw testy integracji na przypadki integracji oddzielonych elementów (innymi słowy nie testuj testami integracji rzeczy, które mogą być testowane testami jednostkowymi).
Zgadzam się. Twoje testy muszą być skupione. Nie testuj przez graficzne interfejsy użytkownika. Nie testuj przez serwery webowe. Testuj najbliżej kodu, jak tylko się da.
6. Nie używaj Cucumbera, no chyba, że żyjesz w magicznym świecie nie-programistów-piszących-testy (i wyślij mi butelkę soku z gumijagód, gdy już tam będziesz!)
Zgadzam się i nie zgadzam się. Cucumber (i język Gherkin) jest wart uwagi tylko jeżeli masz ludzi biznesu i/lub testerów, którzy chcą czytać Twoje testy. Jeżeli Oni również chcą pisać testy akceptacyjne, wtedy: KONIECZNIE wyślij ten sok z gumijagód wszem i wobec; ponieważ jest wart swojej wagi w diamentach.
7. Nie zmuszaj się do testowania najpierw każdego kontrolera, modelu i widoku (mój stosunek jest zwykle 20% testów najpierw, 80% testów potem).
Zgadzam się... tak jakby. Niektóre kontrolery, modele i widoki są zbyt głupie, żeby je testować. Jeżeli są ewidentnie poprawne, ponieważ są jedną linią kodu, testowanie ich może okazać się zbędne. Ale bądź ostrożny. Czasami jedna linia kodu ma 20 linii znaczeń.(*) Ktoś mi wskazał, że post "TSA" w zasadzie poprzedza post "TDD id Dead" o kilka lat. Z jakiegoś powodu miałem dostęp do dwóch poprzednich (ech).
Powyższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :
http://blog.cleancoder.com/uncle-bob/2017/03/06/TestingLikeTheTSA.html
Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.
Brak komentarzy:
Prześlij komentarz