Czy jest możliwe wprowadzenie Test Driven Development (TDD) w dojrzałym projekcie?

Question

• Powiedzmy, że zbyt późno osiągnęliśmy wartość TDD. Projekt jest już dojrzały, wielu klientów zaczęło go używać.
• Powiedz, że testowanie automatyczne jest głównie testowaniem funkcjonalnym/systemowym i jest dużo zautomatyzowanego testowania GUI.
• Załóżmy, że mamy nowe żądania funkcji i nowe zgłoszenia błędów (!). Tak wiele rozwoju trwa nadal.
• Uwaga: istnieje już wiele obiektów biznesowych bez lub z niewielkimi testami jednostkowymi.
• Zbyt duża współpraca/relacje między nimi, która ponownie jest testowana tylko na wyższych poziomach testów funkcjonalnych/systemowych. Bez testów integracyjnych jako takich.
• Duże bazy danych w miejscu z dużą ilością tabel, widoków itp. Wystarczy, aby utworzyć instancję pojedynczego obiektu biznesowego, która już zawiera wiele cennych wycieczek do bazy danych.

Jak możemy wprowadzić TDD na tym etapie?

Kpiny wydają się być właściwą drogą. Ale ilość kpiny, którą musimy tutaj zrobić, wydaje się zbyt duża. Wygląda na to, że należy opracować rozbudowaną infrastrukturę dla systemu szyderczego działającego na istniejące elementy (BO, bazy danych itp.).

Czy to oznacza, że ​​TDD jest odpowiednią metodologią tylko wtedy, gdy zaczyna się od zera? Chciałbym usłyszeć o możliwych strategiach wprowadzenia TDD w już dojrzałym produkcie.

Answer 1

Tworzenie złożonej, kpiącej infrastruktury prawdopodobnie po prostu ukryje problemy w kodzie. Polecam zacząć od testów integracyjnych, z testową bazą danych, wokół obszarów kodu bazowego, które planujesz zmienić. Gdy masz wystarczającą liczbę testów, aby upewnić się, że nic nie zepsujesz, jeśli dokonasz zmiany, możesz rozpocząć przekształcanie kodu, aby uczynić go bardziej testowalnym.

Se także Michael Feathers doskonała książka Working effectively with legacy code, to musi przeczytać dla każdego, kto myśli o wprowadzeniu TDD do starszej podstawy kodu.

Answer 2

Tak, można. Nie rób tego od razu, ale przedstaw, co potrzebujesz, aby przetestować moduł za każdym razem, gdy go dotkniesz.

Możesz także rozpocząć od testów akceptacji na wyższym poziomie i od tej pory stamtąd udać się w dół (spójrz na numer Fitnesse).

Answer 3

Wydaje mi się, że całkowicie możliwe jest wprowadzenie TDD do istniejącej aplikacji, w rzeczywistości ostatnio zrobiłem to sam.

Najłatwiej jest kodować nowe funkcje w trybie TDD i restrukturyzować istniejący kod, aby to uwzględnić. W ten sposób zaczynasz od małej części testowanego kodu, ale efekty zaczynają rozprzestrzeniać się poprzez całą podstawę kodu.

Jeśli masz błąd, napisz test jednostkowy, aby go odtworzyć, w razie potrzeby zreorganizuj kod (chyba, że ​​wysiłek naprawdę nie jest tego warty).

Osobiście uważam, że nie ma potrzeby zwariować i próbować modernizacji testów w istniejącym systemie, ponieważ może to być bardzo uciążliwe bez ogromnej korzyści.

Podsumowując, zacznij od małej, a Twój projekt będzie coraz częściej infekowany.

Answer 4

Tak, możesz.Z twojego opisu projekt jest w dobrej formie - solidna ilość automatyzacji testów funkcjonalnych jest drogą do zrobienia! W niektórych aspektach jest to nawet bardziej użyteczne niż testowanie jednostkowe. Pamiętaj, że TDD! = Testowanie jednostkowe, chodzi o krótkie iteracje i solidne kryteria akceptacji.

Należy pamiętać, że posiadanie istniejącego i zaakceptowanego projektu w rzeczywistości ułatwia testowanie - działająca aplikacja to najlepsza specyfikacja wymagań. Więc jesteś w lepszej pozycji niż ktoś, kto ma tylko kawałek papieru do pracy.

Po prostu zacznij pracować nad swoimi nowymi wymaganiami/poprawkami za pomocą TDD. Pamiętaj, że na zmianie metodologii będzie obciążenie (upewnij się, że Twoi klienci są tego świadomi!) I prawdopodobnie spodziewają się dużej niechęci ze strony członków zespołu, którzy są przyzwyczajeni do "dobrych, starych sposobów".

Nie dotykaj starych rzeczy, chyba że musisz. Jeśli będziesz mieć prośbę o ulepszenie, które wpłynie na istniejące rzeczy, poświęć dodatkowy czas na wykonanie dodatkowych ustawień.

Osobiście nie widzę wiele wartości, wprowadzając złożoną infrastrukturę makiet - na pewno nie jest sposobem, aby osiągnąć te same rezultaty w trybie lekkiego ale to oczywiście zależy od okoliczności

Answer 5

chciałbym zacząć z kilkoma podstawowymi testami integracyjnymi. To dostanie wpisowe od reszty personelu. Następnie zacznij oddzielać części kodu, które mają zależności. Pracuj nad użyciem Dependency Injection, ponieważ sprawi, że Twój kod będzie bardziej testowalny. Traktuj błędy jako okazję do napisania testowalnego kodu.

Answer 6

Jednym z narzędzi, który może pomóc w testowaniu starszego kodu (zakładając, że nie możesz \ nie mieć czasu na jego refaktoryzację, jest Izolator Typemock: Typemock.com Umożliwia on wstrzykiwanie zależności do istniejącego kodu bez potrzeby wyodrębniania interfejsów i dlatego, że nie używa standardowych technik refleksyjnych (dynamiczny serwer proxy itp.), ale zamiast tego korzysta z interfejsów API profilera: Używa się go do testowania aplikacji opartych na sharepoint, HTTPContext i innych problematycznych obszarach Polecam ci spojrzeć. (Pracuję jako programista w tej firmie, ale to jedyne narzędzie, które nie zmusza Cię do refaktoryzacji istniejącego kodu źródłowego, oszczędzając czas i pieniądze) Bardzo polecam również "Skuteczne działanie ze starszym kodem", aby uzyskać więcej technik .

Roy