Mam kilka aplikacji, do których chciałbym powrócić i z mocą wsteczną zbudować pakiet testowy (RSpec & Ogórek), ale jest trochę zniechęcający do rozpoczęcia tego procesu.Szyny: Dobry proces dodawania testów z mocą wsteczną?
Jaki byłby Twój proces powrotu do istniejącej aplikacji i stworzenia dla niej zestawu testów?
Niedawno zacząłem zajmować się dodawaniem testów do starej wersji kodu, a to, co znalazłem niezmiernie pomocne, to rcov (nie zawracam sobie głowy rcov rails plugin i po prostu cd, aby przetestować i uruchomić mały skrypt powłoki, który uruchamia rcov z odpowiednimi wykluczeniami i otwiera raport, jeśli wszystkie testy minie.) Następnie zacząłem zajmować się tymi, które były najbliższe 100% pokrycia i po prostu pracowałem nad procentach bit po bicie. Jest to o wiele bardziej wymierny postęp niż "Ugh, od czego zacząć od dodania do tego testów ?!"
Świetna sugestia i naprawdę pomocna! – Shpigford
Ostatnio robię to dużo dla projektów klientów. Największe bloki dla mnie wydają się być szalonym użyciem wbudowanego javascript z lub bez RJS. [Nota boczna: jest dobry i zły sposób na AJAX, a większość ludzi robi Doing It Wrong ™.] Zazwyczaj używam ogórka z odrobiną rspec do dziwnych testów jednostkowych.
Zmienne, które należy wziąć pod uwagę, są różnorodne, ale dobrym miejscem na rozpoczęcie jest kilka testów jednostkowych dla modeli. Utwórz kilka fabryk i przetestuj swoje sprawdzania poprawności, a także wszelkie niestandardowe zachowania, które Twoim zdaniem wymagają testowania.
Jeśli tego nie robisz lub masz już zestaw testów jednostkowych i chcesz dodać integrację, następnym pytaniem jest stopień, w jakim robisz dużo wbudowanego javascriptu lub RJS. Jeśli twoja aplikacja jest bardzo "ajaxy", musisz zacząć od kierownika selenu do ogórka, który jest wolny jak melasa w lutym, ale to dostanie zadanie. Kiedy już dostaniesz zestaw testów obejmujących pełną funkcjonalność (lub nawet tylko ważne rzeczy) dla twojej aplikacji, zacznę refaktoryzować javascript aby działał dyskretnie.
Kolejny kierunek można przejść byłoby zbudować dodatkowe rspecs dla kontrolerów i widoków, ale ja nie lubię tego wzoru jak pakujesz testowania realizacjęzamiast funkcjonalności.
Należy pamiętać, że nie wszystko musi nastąpić z dnia na dzień. Przeanalizuj swoje przepływy pracy (np. Logując się, wykonując zadanie A, wykonując zadanie B, itp.) I ustal, które z nich pokrywają 80% Twoich typowych przypadków użycia. Przetestuj najpierw te. Następnie użyj czegoś takiego jak metric_fu lub po prostu rcov (lub dowolnego innego narzędzia pokrycia) i znajdź obszary kodu, które są logiczne i niesprawdzone. Podoba mi się metric_fu, ponieważ zestaw narzędzi, które uruchamia, może dostarczyć obu tych informacji.
Najpierw dodam testy wysokiego poziomu (ogórek). To da ci pewność, że zachowanie nie zmieni się niezauważone. Nie chciałbym dodawać testów rspec (a może tylko kilku ważnych), ponieważ prawdopodobnie będziesz chciał również dużo refaktoryzować.
Następnie uruchom metrics. MetricFu Ostatnio dostałem metrykę o nazwie "HotSpots", która połączy inne dane i wskaże największe problemy w kodzie. Miejsca te są zazwyczaj najbardziej istotne dla twojej aplikacji. Napraw je na tyle, aby były czytelne i masz dobre wyczucie, o co chodzi. Nie wychodź jeszcze za burtę.
Następnie dla każdej nowej funkcji, którą dodasz, dodaj specyfikacje i wyczyść kod, z którym współpracujesz. Przetestuj i zmień zależności nowych funkcji, ale nie przekraczaj tego. Zrób to w małych kawałkach lub szybko stracisz nadzieję.
Jestem trochę off topic tutaj, ale w każdym razie ...
myślę, testowanie jednostkowe modeli w szynach (co najmniej 3) jest rodzajem bezwartościowy ... Mam na myśli zwłaszcza gdy kod jest napisane , więc nie robisz TDD. Chcesz przetestować swoją walidację? Czemu ? Po prostu przeczytaj kod, a sam sam odkryjesz błędy. Mówię, że szyny zapewniają (w pewnym miejscu) taką ludzką składnię, że byłoby wstydem ją przetestować.
W mojej opinii, taka składnia sama w sobie jest specyfikacją. Dlaczego warto napisać test?
I tylko dla jasności: Nie, nie mówię, że testowanie jest bezużyteczne przez cały czas. Nie pracuję w jakiejś przypadkowej agencji internetowej ...: p
Rozumiem twój punkt widzenia. Jeśli jednak nie masz pewności, dodaj specyfikację. Jeśli to zachowanie aplikacji, powinieneś ją przetestować. Modele są główną częścią twojej logiki biznesowej, więc twierdzę, że większość testów jednostkowych/specyfikacji dotyczy modeli. – iain
Rzeczywiście. Podsumowując mój punkt: jeśli składnia języka wygląda jak czytelna dla biznesu, to dlaczego testy? –
Aby zabezpieczyć się przed regresjami, gdzie zapisujesz dodatkowy kod, łamie starą funkcjonalność. Chyba, że planujesz ponownie przeczytać kod za każdym razem, gdy dokonasz zmiany ... – Gareth
+1, ponieważ zadawałem sobie to samo pytanie –