Pierwsze kroki z TDD?

Question

Jesteśmy w początkowej fazie prób wdrożenia TDD. Demonstrowałem zestaw kodów Visual Studio Team System/TDD, a zespół jest podekscytowany możliwościami. Obecnie używamy Devpartner do pokrycia kodu, ale chcemy go wyeliminować, ponieważ jest drogi. Mamy bardzo ograniczone doświadczenie w TDD i chcemy mieć pewność, że nie pójdziemy źle. Obecnie korzystamy z SourceSafe do kontroli kodu źródłowego, ale w ciągu roku przeprowadzimy migrację do Team System.

Mogę powiedzieć, że nasze aplikacje są bardzo skoncentrowane na danych. Mamy około 900 tabel, 6000 procedur przechowywanych i około 45 GB danych. Mamy wiele obliczeń opartych na danych użytkownika i różnych stawkach w systemie. Również wiele z naszego kodu opiera się na czasie (należy obliczyć odsetki do bieżącej daty). Niektóre z tych obliczeń są bardzo złożone i bardzo intensywne (tylko kilka osób zna szczegóły niektórych z nich).

Chcemy wdrożyć TDD, aby rozwiązać problemy z kontrolą jakości. Wielu programistów jest zmuszonych naprawić błędy w obszarach, które nie są im znane, i ostatecznie coś zepsuje. Istnieją również obszary, których programiści prawie boją się dotknąć, ponieważ kod jest używany przez wszystko w systemie. Chcemy złagodzić ten problem.

Obawiam się, że nasz kod jest tak skoncentrowany na danych, że wdrożenie TDD może być nieco bardziej skomplikowane niż w przypadku większości systemów. Próbuję wymyślić gameplan, który mogę przedstawić zarządowi, ale mam nadzieję, że nie wpadnę w niektóre błędy początkujących graczy TDD. Również jeśli narzędzia/wyposażenie w Team System sprawią, że TDD będzie bardziej kompletny, byłoby to miłe, ale nie chcemy czekać na uruchomienie systemu Team System.

Pierwsze pytanie, które zadajemy, to czy powinniśmy zacząć od narzędzi w visual studio? Czytałem post, gdy ludzie narzekali na wewnętrzne narzędzia w studio graficznym (trzeba utworzyć oddzielny projekt, aby stworzyć swój test), ale jedyną rzeczą na temat narzędzi w visual studio jest to, że są darmowe, a integracja jest dobra. Jeśli zdecydujemy się na inną drogę przy użyciu czegoś takiego jak XUnit, MBUnit lub NUnit, to najprawdopodobniej będziemy mieli kilka znaczących kosztów:

1) Jeśli chcemy integracji IDE (nie wspomnieliśmy o większości naszego kodu to jest VB.Net)
---TestDriven.Net lub Resharper lub ?????

2) Jeśli chcemy pokrycie kodu
--- NCover (wydaje się dość drogie ze względu na funkcjonalność)

Również widziałem jakiś dość chłodny funkcjonalność demoed w visual studio 2010. Podobnie jak zdolność do zrobienia wejście testowanie (dane wprowadzane w formularzu) lub możliwość zapisania, co zrobił użytkownik, a następnie wprowadzenie go do testu urządzenia w celu odtworzenia problemu.

Ponadto, chociaż nie do końca rozumiem koncepcję obiektu szyderczego, wiem, że wielu ludzi czuje, że to konieczne. Pytanie brzmi, czy wszystkie szydercze fragi mogą być podłączone do wersji TDD (MSTEST) studia Visual Studio?

Poinformowałem kierownictwo, że prawdopodobnie powinniśmy po prostu dodać testy regresyjne w przyszłości (nowe rozwiązania lub znalezione błędy), ale nie próbować przechodzić przez cały nasz kod i wprowadzać testów jednostkowych. Byłby zbyt duży projekt.

W każdym razie byłbym wdzięczny za pomoc.

Answer 1

Pierwszą rzeczą do zrobienia jest dostać tej książki:

Working Effectively with Legacy Code

Dla takiego dużego projektu, przeczytać i przyswoić ją. TDD w aplikacji opartej na danych jest wystarczająco trudne. W przypadku starszych, potrzebujesz poważnego planowania i wysiłku. Warto to moim zdaniem, ale nadal jest to duża krzywa.

Answer 2

1) Używam TestDriven.NET i lubię go tak +1 ode mnie dla tej
2) pokrycie kod jest przydatna, gdy myślał o w dobrym nastroju:
zasięg Wysoka kod robi niekoniecznie oznacza testy jednostkowe wysokiej jakości, ale ...
Wysokiej jakości testy jednostkowe nie oznaczają dużego zasięgu kodu.

Użyłem tylko NCover, więc nie mogę polecić alternatyw.

Jeśli chodzi o szyderstwo - gdy zrozumiesz, o co chodzi i co to dla Ciebie znaczy, zobaczysz korzyści, które oferuje. Mianowicie oznacza to, że nie jesteś zależny od integracji testowanego kodu z zewnętrzną zależnością, a także pomagasz ograniczyć czas wykonywania tekstu (np. Kpiny z warstwy dostępu do danych uniemożliwiają kosztowną interakcję z bazą danych). Jest to ważny czynnik w mojej opinii, jak gdyby testy trwały długo, ludzie mogą zacząć nie przejmować się nimi, jeśli to oznacza, że ​​muszą czekać zbyt długo! Używam NUnit, który ma wsparcie dla wbudowanych mocks.

Zawiąż podejście TDD z ciągłym środowiskiem integracyjnym (np. CruiseControl.NET) i masz bardzo wydajną i wydajną konfigurację.

Podczas rozpoczynania testów TDD/unit zawsze polecam pisanie testów kodu napisanego od "teraz" i nie skupianie się zbytnio na pisaniu testów dla starszego/istniejącego kodu. Jest to o wiele trudniejsze do zrobienia w ogóle i znacznie droższe pod względem czasowym, szczególnie jeśli kod jest stary/wcale nie jest świeży!

Aktualizacja: Aby wyjaśnić mój ostatni punkt nieco dalej, w odpowiedzi na komentarz Roberta ...

Kiedy próbujesz wstać i działa z testów TDD/jednostkowej i nabierać tempa z całością Zespół, chcesz, aby to było jak najbardziej pozytywne i produktywne. Pisanie testów dla starego kodu, który nie jest zmieniany w tym początkowym okresie, jest kosztowne w porównaniu z nowym kodem, ponieważ kod nie jest świeży, dokładne zawiłości tego więcej niż prawdopodobnie muszą być opracowane ponownie, a niekoniecznie przez pierwotnego programistę. Plus fakt, że może ci się wydawać, że trudno jest usprawiedliwić biznes, czas potrzebny na powtórzenie starego kodu, aby pisać testy dla nich, zamiast pracować nad nową funkcjonalnością/naprawiać prawdziwe błędy/problemy.

To może stać się negatywnym doświadczeniem - programista, któremu zlecono pisanie testów na stary kod, o którym wie/pamięta niewiele, sprawi, że będzie trudniej go wykonać, a zatem ich pierwsze doświadczenie nie jest pozytywne. Musisz również zachować ostrożność w tej sytuacji, ponieważ możesz skończyć się słabymi testami, które dają ci fałszywe zaufanie. Z mojego doświadczenia wynika, że ​​absolutnie krytyczne jest, aby każdy odniósł się do tego pozytywnie, w przeciwnym razie pewność siebie/motywacja zanika, a wynik końcowy jest znacznie gorszy.

jestem nie rzeczywiście mówiąc nie należy dodać testy dla starszych kod - robię sobie kiedy pracuję w lub wokół starszego kodu, który nie ma żadnych badań w celu bit po bicie, poprawy Pokrycie testowe i jakość. Różnica polega na tym, że jestem już na pokładzie procesu, "wierzący". To są wczesne etapy, które są kluczowe ...stąd mój punkt widzenia nie skupiając za dużo na starszym kodzie na początku.

Answer 3

Cóż, chciałbym rozpocząć od zalecenia firmy konsultingowej, która zna TDD, aby pomóc Twojemu zespołowi w rozpoczęciu pracy. Jest to szczególnie ważne, jeśli nie masz nikogo w zespole, który jest obeznany z TDD, testowaniem jednostkowym, szyderstwem itp. Nie jestem pewien, ile już masz w zakupie od kierownictwa lub zespołu, ale nie wiesz Chcesz swojej pierwszej próby porażki, z powodu błędów, którym można było zapobiec, zatrudniając specjalistę, który pomoże ci podjąć te pierwsze kroki.

W każdym razie, polecam zacząć od małej i wybrać nowy projekt, który nie jest bardzo duży. Nawet mały podzbiór większego projektu zadziałałby. Wykorzystaj to zarówno jako miejsce, w którym zespół zapozna się z TDD, jak i pokaż kierownictwu, że jest to wykonalne. Następnie, gdy zespół jest bardziej zorientowany, możesz wybrać większe projekty. Jak dla starszych kod Polecam patrząc na tej książki:

Praca Skutecznie z Kodeksem Legacy, Michael Feathers

Także ja na pewno polecam przyjrzeniu się tej książki:

Sztuki testów jednostkowych, Roy Osherove

To może nie być książka TDD, ale jest to świetna książka do nauki o testach jednostkowych, szyderczych frameworkach, a nawet ma rozdział o starym kodzie. Zawiera również zalecenia dotyczące tego, w jaki sposób uzyskać kupowanie zespołu i zarządzania. Mówi trochę o TDD, testach integracyjnych, organizowaniu bazy kodu oraz szeroko pojętym sprawdzianem jednostek. W sumie świetna lektura.

Mam nadzieję, że to pomoże.

Answer 4

100 kciuków za skuteczną pracę ze starszym kodem zalecanym przez Yishai. Polecam również Pragmatic Unit Testing in C# with NUnit jak używasz .NET (chociaż zakładam C#). Jest bardzo przydatny do nauczania podstaw testów jednostkowych, zapewniając solidne podstawy do pracy.

Answer 5

Nie spiesz się i na litość boską, nie próbuj zmuszać programistów do wykonywania TDD.

W przeciwnym razie - dostaniesz bałagan niskiej jakości "testów", które zostaną usunięte po kilku miesiącach i deweloperów, którzy nigdy więcej nie będą chcieli słyszeć o TDD.

Najważniejsze wymaganie dla TDD - dobra znajomość tego, jak pisać testy (dość oczywiste, dlaczego).

Drugie wymaganie - dobra znajomość używanych technologii.
To dlatego, że jeśli trudno jest coś zakodować, projektowanie kodu w głowie będzie niemożliwe.

Używane narzędzia faktycznie nie są ważne.

P.s. ton starego kodu i aplikacja skoncentrowana na danych => dobra forma na katastrofę.

Answer 6

Przez kilka lat zdawałem sobie sprawę z testów jednostkowych i pofatygowałem je. To, co pozwoliło mi naprawdę zaangażować się w testowanie jednostkowe, było wtedy, gdy zacząłem pracować nad projektem open source z imponującym zasięgiem testów. Naprawdę uderzyło mnie, że sposób, w jaki pisałem oprogramowanie, był "po złej stronie historii".

Wspomniałeś wiele narzędzi, których reklamowane możliwości ekscytują Cię i zastanawiały się, jak je połączyć.Myślę, że te pytania są bardzo dobrze adresowane przez "wzorce testowe xUnit", od Addison-Wesley (http://xunitpatterns.com/). Ta książka pozwoliła mi zebrać wszystkie te narzędzia i techniki, o których czytałem w przeszłości.

Książka może lepiej służyć publiczności, która również docenia inne książki, takie jak Wzorce projektowe Gang Czterech, Refaktoryzacja i Refaktoryzacja do Wzorów. Te książki też są świetne, chociaż nie miały tak bezpośredniej zmiany w sposobie kodowania po przeczytaniu ich. Prezentacja wzorców testowych XUnit odzwierciedla styl książek. Początkowo mogą być trudne do odczytania, ponieważ mają tendencję do krzyżowania rozdziałów z odniesieniami w dowolnych kierunkach. Myślę, że są bardzo solidne.

GoF przedstawił kategorie wzorów - kreacyjne, strukturalne i behawioralne. Te kategorie służą jako sposób na powiązanie i przeciwdziałanie wyjaśnionym wzorcom. Dzięki powiązaniu wzorców projektowych testów z typowym czasem trwania testu jednostkowego, wzorce testowe XUnit łączą ze sobą szereg technik dostępnych do testowania jednostkowego. Te same kroki są używane do łączenia i kontrastowania różnych narzędzi używanych do testowania jednostek konstrukcyjnych.

Pomoże to w widoku wysokiego poziomu i przejdzie do rzeczywistej realizacji.

Moja jedyna krytyka wzorców testowych XUnit to stopień, w jakim tekst krytykuje NUnit. NUnit to świetny program do jego autora, NUNIT, o którym tak głośno wspominamy w tym, co moim zdaniem stanie się klasyczną książką.

Answer 7

Jeśli chodzi o rozpoczęcie, polecam również przeczytanie Fowlera: Refactoring. Pierwszy rozdział daje dobre wyczucie tego, co oznacza wprowadzenie testów, a następnie bezpiecznie wprowadza zmiany (choć nacisk kładzie się na zachowania zachowujące zmianę). Ponadto, rozmowa this opisuje niektóre praktyki, które mogą pomóc w ulepszeniu testowalności twojego kodu. Misko Hevery ma także this przewodnik pisania testowalnego kodu, który podsumowuje przemówienie.

Z Twojego opisu brzmi to tak, jakbyś chciał przetestować główne części systemu - części z wieloma zależnościami, w których zmiany są przerażające. W zależności od stopnia, w jakim dostęp do danych jest oddzielony od logiki biznesowej, prawdopodobnie będziesz musiał dokonać refaktoryzacji w kierunku stanu, w którym kod jest bardziej testowalny - gdzie jest łatwo i szybko tworzyć zbiory danych testowych w celu weryfikacji logiki w izolacji . Może to być wielka praca i może nie być warta wysiłku, jeśli zmiany są rzadkie, a baza kodów jest dobrze sprawdzona.

Moja rada byłaby pragmatyczna i skorzystałam z doświadczeń zespołu, aby znaleźć obszary, w których najłatwiej jest dodać testy, które dodają wartości. Uważam, że posiadanie wielu ukierunkowanych testów jednostkowych jest najlepszym sposobem na podniesienie jakości, ale prawdopodobnie łatwiej jest przetestować kod na wyższym poziomie za pomocą testów integracyjnych lub scenariuszy, na pewno na początku. W ten sposób możesz wcześnie wykryć duże awarie w swoich podstawowych systemach. Wyjaśnij, na czym polegają twoje testy. Testy scenariuszowe obejmie wiele kodu, ale prawdopodobnie nie ujawni subtelnych błędów.

Przejście z SourceSafe do Team System to duży krok, jak duże zależy od tego, ile chcesz zrobić w Team System. Myślę, że możesz zyskać dużą wartość dzięki zastosowaniu wbudowanego testowego środowiska Visual Studio. Na przykład jako pierwszy krok można wdrożyć kilka podstawowych zestawów testów dla podstawowych przypadków użycia systemu/rdzenia. Programiści mogą uruchamiać je samodzielnie w Visual Studio, gdy pracują i przed zameldowaniem. Te pakiety mogą być stopniowo rozszerzane. Później, gdy otrzymasz TFS, możesz sprawdzić, czy uruchamiasz te pakiety podczas odprawy i jako część automatycznego procesu budowania. Możesz podążać podobną ścieżką niezależnie od konkretnych narzędzi.

Od samego początku należy jasno określić, że koszty utrzymania kodu testowego są wysokie, a dobrze zaprojektowane testy mogą wypłacać dywidendy. Widziałem sytuacje, w których testy są kopiowane, a następnie edytowane, itp.Powtórzenie kodu testowego w ten sposób może spowodować eksplozję liczby linii kodu testowego, które musisz zachować, wprowadzając drobną zmianę kodu produktu. Ten rodzaj kłopotów może podważyć postrzeganą korzyść z posiadania testów.

Program Visual Studio 2008 wyświetli tylko pokrycie bloku, chociaż analiza kodu da również inne parametry, takie jak złożoność cykliczna na zespół/klasę/metodę. Uzyskanie wysokiego poziomu pokrycia testami jest z pewnością ważne i pozwala łatwo zidentyfikować obszary systemu, które są całkowicie niesprawdzone.

Uważam jednak, że ważne jest, aby pamiętać, że wysoki zasięg bloku to tylko prosty pomiar skuteczności testów. Załóżmy na przykład, że napisałeś klasę, aby wyczyścić archiwum plików i zachować 5 najnowszych plików. Następnie wypiszesz przypadek testowy, który sprawdza, czy zaczynasz od 10 plików, a następnie uruchamiasz oczyszczarkę, którą pozostałoś 5. Implementacja, która przejdzie test, może usunąć najnowsze pliki, ale może z łatwością dać 100% pokrycia. Ten test sprawdza tylko 1 z wymagań.