Czy muszę wszystko testować?

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?

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”.

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ś.

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.

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.

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 .

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.

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.

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

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.

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.

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 ...