Czy muszę wszystko testować?

28

Zacznę swój pierwszy prawdziwy projekt w Ruby on Rails i zmuszam się do napisania testów TDD . Nie widzę prawdziwych korzyści z pisania testów, ale ponieważ wydaje się to bardzo ważne, spróbuję.

Czy konieczne jest przetestowanie każdej części mojej aplikacji, w tym stron statycznych?

Matteo Pagliazzi
źródło
9
To naprawdę nie jest pytanie rubinowe na szynach. to bardziej pytanie TDD.
Jon Strayer
4
@JonStrayer: Czy to jest? Czy jesteś pewien, że odpowiedź byłaby taka sama dla RoR jak .NET? Sugerowałbym, że z założenia RoR celowo obniżył koszty testowania, nie mając jednak bezpieczeństwa typu w postaci kompilatora, znacznie zwiększa korzyści z testowania.
pdr
1
Z jakiegoś powodu to pytanie sprawia, że ​​chcę opublikować makro obrazka kapitana Nerona krzyczącego „TESTUJ WSZYSTKO !!!”
Mason Wheeler,
3
Nie dostrzeganie prawdziwej przewagi w pisaniu testów i pisaniu ich z ślepej wiary nie brzmi właściwie dobrze. Kontynuuj bez pisania testów, po chwili doświadczysz nieoczekiwanej regresji i będziesz wiedział, dlaczego testujesz.
ZJR
1
Poczekaj, aż zdecydujesz się zrestrukturyzować kod. Za każdym razem, gdy wprowadzane są ogromne zmiany, musisz zweryfikować funkcjonalność. Bez testów musisz przejść przez aplikację i przetestować całą funkcjonalność ręcznie. Wprowadź kolejną dużą aktualizację, a będziesz musiał to zrobić ponownie. Testy jednostkowe to tylko „tani” sposób upewnienia się, że wszystko działa zgodnie z oczekiwaniami.
Evan Plaice,

Odpowiedzi:

47

TDD nie polega na testowaniu, ale na projektowaniu. Pisanie testów zmusza cię do zastanowienia się, jak powinna działać klasa i jakiego rodzaju interfejsu potrzebujesz. Testy to szczęśliwy efekt uboczny, który ułatwia późniejszą refaktoryzację.

Mając to na uwadze, jakie jest zachowanie strony statycznej i jaki jest interfejs?

Moja pierwsza odpowiedź to „brak” i „brak”.

Jon Strayer
źródło
więc nie ma testów dla stron statycznych?
Matteo Pagliazzi,
TDD w pewnym stopniu dotyczy projektowania. Ale wciąż potrzebujesz architektury. Nie mając na uwadze architektury, trudno sobie wyobrazić, jak ktoś wyrósłby organicznie z szeregu testów.
Robert Harvey
@MatteoPagliazzi W zależności od poziomu testowania (testy jednostkowe / testy integracyjne / itp.), Być może jeden lub dwa, w celu potwierdzenia, że ​​strony statyczne są dostępne. Ale to zbyt wysoki poziom do testów jednostkowych.
Izkata,
1
@RobertHarvey Nie powiedziałem, nie testuj niczego. Powiedziałem: nie testuj jednostkowo stron statycznych.
Jon Strayer
@JonStrayer: TDD'e mają tendencję do utrzymywania TDD jako magicznego eliksiru do projektowania; Przepraszam, jeśli nie o to ci chodziło. :)
Robert Harvey
32

Zawsze jest to analiza kosztów i korzyści. Ile kosztuje udostępnienie tej funkcji? Jeśli koszt jest wysoki, przetestuj dobrze i dokładnie. Jeśli koszt jest niski, przetestuj go lekko lub wcale.

Należy również wziąć pod uwagę koszt czasu wprowadzenia na rynek. Może lepiej jest dostarczyć funkcję, która działa głównie, niż spóźnić się z funkcją całkowicie działającą.

Prawie niemożliwe jest udzielenie odpowiedzi na te pytania w ogólnym IMO.

Myślę, że ważniejsze jest zachowanie możliwości testowania na wypadek, gdyby okazało się, że jakaś funkcja jest ważniejsza niż początkowo sobie wyobrażałeś.

Doug T.
źródło
Zakładam również, że błędy na stronie statycznej byłyby DUŻO łatwiejsze do naprawienia niż błędy logiczne, błędy projektowe i rodzaj rzeczy, których TDD zwykle używa się w celu zapobiegania. Zarówno wykrywanie, jak i naprawianie błędów stron statycznych może być dość łatwe, a mam wrażenie, że TDD służy do skracania obu tych procesów, gdy zajmują one więcej czasu, niż jest to pożądane. : D
Gordon Gustafson
Nie zakładałbym tego. Jeśli kiedykolwiek miałeś do czynienia z niejasnymi zachowaniami wersji przeglądarki lub dziwnymi problemami z pamięcią javascript, prawdopodobnie dobrze się spisałeś. Czasami języki zaplecza mogą być nieco bardziej niezawodne i standardowe. czasami. Być może mówisz o statycznym jak w HTML i bez javascript.
Michael Durrant
8

Powiedziałbym tak". Jeśli masz testy obejmujące nawet najprostsze funkcje i kod, możesz mieć pewność, że dodanie nowego kodu nie spowoduje, że kod lokalny przestanie działać. Podobnie testowanie każdego napotkanego błędu zapobiega cofaniu się regresji.

Bruce Ediger
źródło
„to możesz mieć pewność, że dodanie nowego kodu nie spowoduje, że kod lokalny przestanie działać” w ten sposób nie powinienem dotykać żadnego napisanego wcześniej kodu i dodawać nowych metod?
Matteo Pagliazzi,
Więc nie. Ale nieprzewidziane i nieplanowane zależności między kodem, który obecnie „działa”, może prowadzić do problemów, jeśli dodasz nowy kod, który zmienia te zależności. Ponadto, jeśli źle zrobisz test, co moim zdaniem jest dość powszechne, musisz zmodyfikować sam test, a następnie być może zmodyfikować kod wynikający z tego testu.
Bruce Ediger,
@Andy To absolutny nonsens. Testowanie obiektów ustawiających i pobierających jest zarówno proste, jak i WITALNE. Jeśli nie działają, ogólnie cała klasa rozpada się. Na przykład w aplikacji wielowątkowej, jeśli zestaw nie zapobiega pobieraniu współbieżnych, dostaniesz uszkodzony problem z danymi, który może zająć wiele godzin, ponieważ źródło danych będzie poprawne, ale wynik będzie nie zrobi tego Lub jeśli Twój zestaw nie zaktualizuje również czasu aktualizacji, wtedy synchronizacja danych może być niemożliwa. Masz pomysł. Gdyby setery i osoby pobierające były naprawdę trywialne, można po prostu upublicznić tę nieruchomość
deworde
@deworde Obawiam się, że zapewnienie członkom instancji bezpiecznego wątku nie jest tak powszechne. Bardziej typowe jest kontrolowanie dostępu do nie-bezpiecznych typów niż próba uczynienia ich bezpiecznymi dla wątków. W każdym razie to, co należy przetestować, jest opłacalne, jak wynika z innej odpowiedzi. możesz poświęcić czas na pisanie testów dla programów pobierających lub ustawiających, lub możesz przetestować rzeczywiste zachowanie, które powinien zawierać system.
Andy,
3

Tak, powinieneś wszystko przetestować ...

Nie będziesz musiał pisać automatycznych testów na wszystko. W przypadku stron statycznych skorzystaj z Selenium http://seleniumhq.org/, aby upewnić się, że wszystko jest w porządku.

Z mojego doświadczenia wynika, że ​​niektóre rzeczy z przodu są prawie niemożliwe do napisania przypadków testowych, ale właśnie dlatego chciałbyś przetestować za pomocą gałki ocznej Mark 1.

Schleis
źródło
Nie zgadzam się. Jeśli nie możesz sprawić, by stało się to przez próbę lub przekazanie danych, to dlaczego masz to w swoim kodzie. Operatorzy pobierający i ustawiający nie potrzebują własnych testów, które zostałyby przetestowane za pomocą innych testów jednostkowych systemu w celu weryfikacji oczekiwanej funkcjonalności.
Schleis,
Oczywiście, ustawiacze / gettery są testowani pośrednio z innymi testami, ale kiedy ktoś mówi „testuj wszystko”, zakładam, że mają na myśli tworzenie testów specjalnie dla tego rodzaju rzeczy. Zawsze mówię ludziom: „przetestuj ważne rzeczy”. Rzeczy takie jak setery i gettery nie pasują do mnie w tej definicji.
Andy
2

Testowanie jest równie ważne jak kodowanie. Musisz usłyszeć powiedzenie „Jeśli coś może pójść nie tak, to będzie”. INMO, Spośród wielu technik inżynierii oprogramowania stosowanych w celu poprawy jakości, Testowanie jest najbardziej wartościowe, ponieważ pomaga wcześnie znaleźć problemy.

Chociaż testowanie wszystkiego nie jest możliwe (szczególnie w małych zespołach i dużych systemach), nie oznacza to, że całkowicie pomijasz testy. Czy testowanie jest tego warte? Zobacz sekcję „Wczesne wykrywanie usterek” w Zobacz Wiki-SoftwareTesting .

Bez szans
źródło
2

Testy TDD mogą również być żywymi specyfikacjami, jeśli zostaną zapisane w ten sposób. Nazwy metod testowych powinny mieć sens dla użytkownika biznesowego.

Chriseyre2000
źródło
2

Jak wspomnieli inni, w testach Ruby on Rails jest to o wiele ważniejsze niż w (większości) innych językach. Wynika to z braku kompilatora.

Języki takie jak Delphi , C ++, VB.NET itp. To języki skompilowane, a Twój kompilator wykryje wiele błędów, takich jak literówki w wywołaniach metody. W Ruby on Rails będziesz wiedział tylko, czy w kodzie jest literówka lub błąd, jeśli ta linia tekstu jest uruchomiona lub używasz IDE, które pokazuje ostrzeżenia wizualne.

Ponieważ KAŻDY pojedynczy wiersz kodu jest ważny (inaczej nie byłoby go tam), powinieneś przetestować każdą pisaną metodę. Jest to o wiele prostsze niż się wydaje, jeśli zastosujesz podstawowe narzędzia TBDD.

Przekonałem się, że Rany Ryana Batesa rzucone na mój test były dla mnie nieocenione i naprawdę podkreśliły prostotę TBDD, jeśli zostały wykonane poprawnie.

jamesc
źródło
1

Jeśli naprawdę używasz metodologii TDD, nie piszesz kodu bez uprzedniego wykonania testu jednostkowego, który próbujesz zdać.

wessiyad
źródło
2
tak ... ale na przykład na stronie statycznej co powinienem przetestować? istnienie tego? że treść i linki istnieją? może się mylę, ale wydaje się to stratą czasu ...
Matteo Pagliazzi,
1
Myślę, że metodologia TDD jest stosowana do twojej logiki. Czy twoja strona statyczna jest plikiem HTML? Widok MVC, który nigdy się nie zmienia? Jeśli chodzi o ten drugi przypadek, myślę, że możesz przetestować, czy kontroler zwraca właściwy widok. Myślę, że ważniejsze jest, aby pamiętać, że TDD powinno pomagać ci rozwijać się zgodnie ze specyfikacją, a nie tylko „testować” ...
wessiyad,
Zakładam, że po prostu podajesz statyczną stronę ze składnikiem frameworka. Jeśli żadna z metod nie dotyka tej strony, w rzeczywistości nie ma nic do przetestowania. Nie musisz także testować Railsów. Myślę, że ktoś to obejmuje.
Erik Reppen
0

Powiedziałbym, żeby nie zaczynać od TDD. Podejmij świadomą decyzję, kiedy poświęcisz więcej czasu na naukę strategii architektury w ogóle. TDD nie pozwoli ci pominąć pracy domowej, chociaż możesz zacząć w to wierzyć.

Oto mój problem z tym. Kiedy mówisz, że wydaje się, że dużo zmarnowanego czasu na rzeczy, które nigdy nie złamią TDDers, powiesz, że docenisz to, gdy jedna rzecz, której nie spodziewałeś się w ogromnym łańcuchu zależności, zostanie zerwana. Kiedy zauważysz, że nie można przewidzieć takich rzeczy przed napisaniem aplikacji, to jest ... dlaczego testujemy, mówią ci, że naprawdę chodzi o projektowanie, a nie testowanie, nawet jeśli testowanie jest przydatne.

Ale czy gigantyczne łańcuchy nieprzewidywalnych powiązanych zależności nie są produktem kiepskiego projektu?

Więc co to jest?

Oto myśl. Nie należy mieć przede wszystkim ogromnych złożonych łańcuchów zależności, biorąc pod uwagę następujące dwie zasady projektowania obiektowego z wzorców projektowych:

„Program do interfejsu, a nie implementacja”

Innymi słowy, twoje przedmioty nie powinny obchodzić, kto wykonuje powołanie i jak zostały wykonane. Tyle tylko, że wprowadzono odpowiednie argumenty i że metody, które wywołują z innych obiektów, są skierowane do pracy zgodnie z oczekiwaniami. Twój łańcuch zależności w większości przypadków powinien znajdować się w jednym punkcie połączenia, wywołaniu metody po stronie wywołującego i miejscu, w którym argumenty są wprowadzane do twoich metod. To tam logujesz się, sprawdzasz poprawność i wysyłasz przydatne wiadomości do debugowania, gdy coś się psuje.

I:

„Preferuj kompozycję obiektów nad dziedziczeniem klas”

Kim jest manekin? Facet, który zrobił coś z klasą w złożonym kaskadowym schemacie dziedziczenia obejmującym około 30 klas, co doprowadziło do zepsucia skrzynki, czy też deweloper, który wymyślił tę architekturę w pierwszej kolejności? TDD może pomóc ci dotrzeć do sedna problemów w tej krzywej wieży klasy Piza wcześniej niż mógłbyś to zrobić bez, ale czy to sprawia, że ​​mniej bolesna jest próba zmodyfikowania jednego z punktów końcowych tej katastrofy kodu następnym razem?

I tutaj dochodzę do rzeczy, która mnie wkurza. Czy TDD naprawdę pomaga w projektowaniu, czy też umożliwia złą architekturę? Wydaje mi się, że może być samospełniającą się strategią. Im bardziej twój zespół nie musi ponosić odpowiedzialności za słabą architekturę, tym bardziej pomocne wydają się te szczegółowe testy, ale ostatecznie twoja aplikacja staje się coraz większą PITA do pracy (zakładając, że nigdy nie myślała o architekturze w pierwszej kolejności miejsce). Nieuwzględnienie konsekwencji tego jest oczywiste, zawsze jest to najdroższy błąd, jaki możesz popełnić podczas pracy z aplikacją, która ma być aktualizowana i modyfikowana w miarę upływu czasu.

Erik Reppen
źródło
-1

Aby odpowiedzieć na pytanie, zastanów się „co może tu pójść nie tak”. W szczególności, jeśli zmienisz „kod” (znaczniki / cokolwiek), w jaki sposób będziesz mieć pewność, że nie złamałeś strony. Cóż, dla strony statycznej:

  • może się nie renderować
  • może renderować się niepoprawnie
  • JS może się nie ładować
  • ścieżki obrazów mogą nie działać
  • linki mogą być zepsute

Osobiście polecam:

  • napisz test selenu [1], który sprawdzi, czy na stronie znajduje się jeden ciąg znaków (w miarę możliwości u dołu). Potwierdza to, że renderuje.
  • sprawdź, czy nie ma błędów JS (myślę, że selen na to pozwala)
  • przeprowadź strony statyczne przez walidator HTML, a jeśli to możliwe, narzędzie do sprawdzania łączy.
  • Nie znalazłem narzędzia, które lubię sprawdzać poprawność JS, ale możesz odnieść sukces dzięki jslint lub jshint.

Chodzi o to, że chcesz czegoś, co jest powtarzalne, łatwe w użyciu i będzie działać automatycznie w twoim testerze.

Paul Biggar
źródło
-1

Aby dodać do wszystkich już doskonałych odpowiedzi, oto moje przemyślenie na temat tego, co przetestować, a czego nie testować:

Wykonaj test:

  • logika biznesowa
  • logika aplikacji
  • funkcjonalność
  • zachowanie,
  • więc wszystko, z wyjątkiem :

Nie testuj:

  • stałe
  • prezentacja

Nie ma więc sensu przeprowadzanie testu, który mówi:

assert wibble = 3

i trochę kodu, który mówi

wibble = 3

Nie ma również sensu testować prezentacji, takich jak to, czy ikona ma kolor perywinkle niebieski, jaką czcionkę użyłeś do nagłówków i tak dalej ...

Pytasz więc „powinienem przetestować strony statyczne”, a odpowiedź brzmi: testujesz je, o ile są one częścią funkcjonalności, logiki biznesowej lub zachowania Twojej witryny.

W naszej aplikacji mamy test, który sprawdza, czy warunki są dostępne z każdej części witryny - dla anonimowych użytkowników, dla zalogowanych użytkowników, z deski rozdzielczej, na ekranach aplikacji itp. Po prostu sprawdza, czy są link o nazwie „warunki” na każdej stronie, że link działa, a następnie test mówi, że gdy dotrze na stronę, „wygląda jak” OW - wystarczy, aby upewnić się, że jest to właściwa strona, bez „testowania stałej” lub „testowania prezentacji” ... abyś mógł sprawdzić, czy tekst jest poprawny, na przykład bez sprawdzania określonego rozmiaru czcionki lub układu tekstu ...

hwjp
źródło