Słyszałem, że pisanie (kodowanie) testów jednostkowych dla aplikacji skutecznie podwaja czas potrzebny na opracowanie projektów. Czy to prawda, szczególnie dla początkujących?Testowanie jednostek - o ile więcej czasu to naprawdę dodaje?
Również niektóre pytania uzupełniające (punkty ciasteczka): Jeśli robiłeś projekt klienta, który oddajesz po zakończeniu, czy warto poświęcić czas i wysiłek, aby przeprowadzić test jednostkowy?
Powiedziałbym, że podwójny czas jest uzasadniona szacunek i tak, testów jednostkowych jest zawsze warte czasu i wysiłku.
Jednak twierdzę, że czas spędzony na testowaniu jednostkowym jest znacznie krótszy niż czas potrzebny na debugowanie i naprawianie błędów później, które wynikały z braku testów jednostkowych.
z wyjątkiem: gdy testy są napisane, ale nie są utrzymywane. –
@Mitch - Dobra uwaga. –
Powodem, dla którego warto, jest to, że zmniejsza ilość czasu poświęcanego na debugowanie. Z przyzwoitym pokryciem niższych warstw logiki, wiele zgadywanek i dziwnych piłek nie wchodzi w grę podczas debugowania aplikacji. Powodem, dla którego warto wspomnieć o niższych warstwach, jest to, że czasami pisanie testów jednostkowych dla rzeczy na wyższym poziomie wymaga dużo przygotowania, zastrzyku rzeczy, które nie są dostępne itd. Tak więc, na pewno załatwisz łatwiejsze rzeczy. – mjv
Testy jednostkowe służą również do dokumentowania bazy kodu w zakresie tego, jak używać/wywoływać określoną klasę/metodę.
Twierdzę, że czas pisania automatycznych testów jednostkowych jest różny w zależności od języka i sposobu, w jaki się rozwijasz. Na przykład pisanie C# o bardzo proceduralnym stylu może prowadzić do trudnych do opracowania testów. Jeśli jednak podejmiesz inne podejście, np. Używając pewnych szyderstw i układów IOC, czas testowania jednostkowego może drastycznie się zmniejszyć.
Myślę, że to zależy ... na jakiej wysokości pokrycia testowego ty kierowania
Jeśli zamierzają podążać prawdziwą definicję TDD, gdzie każda linia kodu jest testowane przez badanej jednostki Torby i futerały- was mogą szuka ogromnego wysiłku
Ale to nie musi być tak, że
można znaleźć własną równowagę ...
W moim experiences- ja nie uważam, aby podwoić czaso- choć dodaje współczynnik (20-25%?)
Mam na myśli - nawet jeśli nie miałeś przypadków testowych jednostek - nadal robiłbyś to ręcznie, testując urządzenie - prawda?
Over czasie projektu- widać, że czas spędzony na testach jednostkowych jest recvered dość łatwo
Dla klienta projects- IMHO tak. Miejmy nadzieję, że docenią wysiłek.
Na temat dodanego czasu, ponieważ wspomniałeś, że jesteś początkującym: im szybciej znajdziesz zestaw testów jednostkowych, który pasuje do twoich potrzeb, tym lepiej. Nie wspominałeś, z jakiego języka korzystasz, ale jeśli nie ma wsparcia dla refleksji (na przykład C, C++), ustawienie instalacji testujących jednostki będzie trwało znacznie dłużej, ponieważ musisz utworzyć instancję TestSuite, i Test, i musisz zarejestrować Test, itp. To wszystko dużo rzeczy do nauczenia się, gdy wszystko, co chcesz zrobić, to uruchomić kilka testów!
Z drugiej strony, jeśli używasz bardziej dynamicznego języka, na przykład Python, możesz prawie skonfigurować testy jednostkowe, prawie nie znając testów jednostkowych, wykonując kilka metod testXXX za pomocą modułu unittest.
Odnośnie drugiego pytania, postawcie się w roli klienta - czy nie chcielibyście usłyszeć, że produkt, który kupiliście został gruntownie przetestowany? Oni (prawdopodobnie) kochają numery!Powiedz im, że masz skonfigurowane testy automatyczne, przeprowadzono ponad 500 indywidualnych testów, ponad 80% kodu zostało przetestowane w ten sposób - cóż, tylko powiedz im prawdę, ale masz rację. To dodaje ogromną wartość w zakresie zaufania do kodu, i szczerze wolę robić interesy z kimś, kto może udowodnić, że to, co zostało przetestowane i co może być niestabilne, raczej niż ktoś, kto po prostu podaje mi coś i mówi: "zrobione."
Dobre spostrzeżenia, dziękuję również za odpowiedź na drugie pytanie. – jimiyash
Właśnie z tego doświadczenia i nie ma za co. –
To, co testujesz, określi, ile czasu to zajmie. Na przykład napisanie testu jednostkowego dla TSQL zajmuje mi znacznie więcej czasu przy użyciu bazy danych testów jednostkowych bazy danych MS niż zapisanie procedury składowanej, ponieważ jest to bardzo ręczny proces przygotowania testu.
Ale jeśli używam Eclipse lub VS2008 dla Javy lub C#, a ja po prostu mówię o tym, aby stworzyć testy, to dość szybko zrobić testy, ponieważ wiele pracy jest dla mnie zrobione.
Zawsze warto jednak, ponieważ pomaga zmniejszyć liczbę prawdopodobnych błędów, ale co ważniejsze, jeśli chodzi o powielanie błędu, to i tak zakończysz pisanie testów, a jeśli nie zaprojektujesz Twoje zajęcia będą podlegały testowaniu jednostkowemu, wtedy będzie wymagać refaktoryzacji, która może wprowadzić nowe błędy, aby naprawić zgłoszony błąd.
To jest jedna ważna rzecz, że odkryjesz, że masz funkcje, które nie są testowalne, więc skończysz refaktoryzację, abyś mógł przeprowadzić rozsądne testy jednostkowe.
Na przykład, jeśli masz funkcję wybieraną z bazy danych, to logika biznesowa wyników, jak to właściwie przetestować? Powinno to być dwie oddzielne funkcje, z kontrolerem, który wywołuje dane, a następnie wywołuje logikę biznesową, więc będziesz miał trzy testy, ale kontroler może przejść do fałszywej bazy danych, ponieważ masz osobny test przetestować warstwę bazy danych.
Dla mojego programowania staram się tylko testować te części kodu, na które nie mogę intuicyjnie spojrzeć i wiem, że to zadziała (co niektórzy twierdzą, że to za mało, ale to ani tutaj, ani tam) .
Programowałem w ten sposób przez długi czas i używam tych testów, aby pomóc mi napisać mój kod w pierwszej kolejności. Biorąc pod uwagę, że czas napisania moich testów nie dodaje w zasadzie nic do mojego ogólnego czasu rozwoju. Jeśli pominąłem pisanie testów, które robię, to "może" zaoszczędzić mi 10% całkowitego czasu, jeśli tak.
Kiedy po raz pierwszy zacząłem używać testów automatycznych, powiedziałbym, że podwojenie całkowitego czasu pisania kodu jest rzetelnym szacunkiem. Ale z biegiem czasu dotarłem do miejsca, w którym nie jestem (dodając, że nie ma czasu). Szczerze mówiąc, jest to coś, do czego się przyzwyczaiłeś i staje się częścią tego, jak projektujesz swój kod.
Edycja: Zdaję mi się dodawać, że są chwile, kiedy pisanie kodu testowego wciąż dodaje sporo czasu do mojego kodowania, czasami znacznie więcej niż dwukrotnie. Biorąc to pod uwagę, czasy te są bardzo nieliczne, ponieważ staram się unikać kodu, który to robi ... jest to dla mnie kodowy zapach.
Jeśli poważnie myślisz o testowaniu jednostkowym, poleciłbym książkę The art of unit testing przez Roy Osherove.
piśmie (Coding) Testy jednostkowe dla aplikacji efektywnie podwaja czas rozwoju wymaganego do projektów.
Pisanie testów jest zdecydowanie wolniejsze niż pisanie żadnych testów, jeśli tylko policzycie czas wpisywania kodu.Jeśli jednak przyjmiesz czas na zerwanie istniejącej funkcjonalności - naprawianie błędów bez siatki bezpieczeństwa testów, korzyści przeważają nad kosztami dla innych niż trywialnych projektów. Testy wspomagają projektowanie (TDD) + obrona (regresja) + dokumentacja (specyfikacje).
Czy to prawda, w szczególności dla początkujących?
To zależy. Parafrazując Becka (chyba), jeśli jesteś głupkiem, narzędzia/met nie pomogą ci, jeśli jesteś bóg-kodowaniem, prawdopodobnie ich nie potrzebujesz. Jednak dla większości z nas w środku pomaga. Gdy poruszasz się w prawo w tym spektrum, rzeczy stają się dla ciebie drugą naturą, musisz "widzieć", co nadchodzi, a czas zaczyna redukować (chociaż nie do zera). Aby uniknąć błędów popełnianych przez rekruta, znajdź kogoś, kto już tam był (uzyskaj pomoc z listy mailingowej lub zatrudnij dobrego trenera na chwilę)
Także kilka pytań uzupełniających (punkty ciasteczka): Jeśli robiłeś projekt klienta, który odłożysz po zakończeniu, czy warto poświęcić czas i wysiłek, by przeprowadzić testowanie jednostkowe?
Nawet jeśli następny zespół rzucił zestaw testów, nadal bym to robił, aby utrzymać produktywność i zmniejszyć czas spędzony na tworzeniu i gonieniu błędów.
+1. Pierwsza część podsumowała to, co chciałem dodać do odpowiedzi Andrew Hare'a. Ponieważ projekt staje się większy, przeprowadzenie testów jednostkowych znacznie ułatwi testowanie i debugowanie. Czas projektowania jest dłuższy bez testów jednostkowych dla nietrywialnych projektów. –
"Parafrazując Becka (myślę), [...]": tak, to był Beck, we wprowadzeniu * TDD przez przykład *. Przeczytałem to dwa dni temu, ale wydaje mi się, że to coś, o czym pamiętasz dłużej :) – bigstones
Nie, jeśli używasz TDD, ponieważ:
rzeczywiście napisać swój pierwszy egzamin. Samo to jest wielką oszczędnością czasu, ponieważ położyłeś to, co masz zamiar zrobić. Wiesz również dokładnie, kiedy przerwać kodowanie. (Kiedy test przejdzie)
Kiedy faktycznie piszesz kod, zaczyna być tak mały, jak to tylko możliwe. Możesz przestać kodować, gdy zdasz test, a następnie możesz zrobić to z większą pewnością, o ile test będzie nadal wykonywany.
Następnie napisz testy dla przypadków brzegowych (jeśli to konieczne) i sprawdź, czy wystąpią problemy.
Robiłem to i stwierdziliśmy, że rzeczywiście skraca czas dev - bo jesteś już myśli o tym, co chcesz zrobić, zanim nawet zacząć pisać rzeczywisty kod, a wiesz kiedy kiedy masz zrobił to, że faktycznie działa.
Zależy od otrzymywanych świadczeń. Jest to kompletna strata czasu dla konwencjonalnych aplikacji internetowych - klienci będą bardziej interesować się pomieszanym interfejsem, niż kodem, który powoli niszczy dane.
Dziękuję za odpowiedzi do tej pory. Przepraszam, zapomniałem dodać, że język, którego używam, to PHP i trochę framework CakePHP. Chciałem jednak, aby było to bardziej ogólne pytanie, aby uzyskać różnorodne odpowiedzi. Jestem również zainteresowany nauką Ruby i Objective-C. – jimiyash