Poszukuję studiów przypadków, w jaki sposób TDD poprawiła jakość i / lub szybkość rozwoju [zamknięte]

W mojej firmie staram się uzasadnić, dlaczego powinniśmy robić TDD. Obecnie większość programistów robi wszystko, co w ich mocy, aby wykonać projekt, a następnie dodaje testy jednostkowe po fakcie, aby spełnić kryteria menedżera. Wszelkie przykłady renomowanych firm wykonujących TDD i widzących korzyści byłyby bardzo mile widziane.

Studium 4 projektów w IBM i Microsoft. Opublikowano w czasopiśmie Emperical Software Engineering .

Badania empiryczne pokazują, że rozwój oparty na testach poprawia jakość

Artykuł opublikowany po raz pierwszy w czasopiśmie Empirical Software Engineering donosi: „TDD wydaje się mieć zastosowanie w różnych dziedzinach i może znacznie zmniejszyć gęstość defektów opracowanego oprogramowania bez znacznego zmniejszenia produktywności zespołu programistów”. W badaniu porównano 4 projekty firm Microsoft i IBM, które korzystały z TDD, z podobnymi projektami, które nie korzystały z TDD ...

Artykuł zawiera 1 studium przypadku w IBM i 3 od Microsoft. Każde studium przypadku porównuje dwa zespoły pracujące nad tym samym produktem, wykorzystujące te same języki programowania i technologie, pod tym samym menedżerem wyższego poziomu, z których tylko jeden korzystał z programowania testowego (TDD). Żaden z zespołów nie wiedział, że będą uczestniczyć w badaniu podczas swoich cykli rozwojowych. Studium przypadku IBM śledziło zespoły zajmujące się rozwojem sterowników urządzeń. Sprawy Microsoft śledziły zespoły pracujące w systemach Windows, MSN i Visual Studio.

Artykuł opisuje praktyki TDD stosowane przez zespoły jako przepływ pracy z minuty na minutę, a także przepływy pracy na poziomie zadania ...

W niedawnej książce „Making Software: Co działa i dlaczego w to wierzymy” jest rozdział o TDD. Ale możesz być rozczarowany, ponieważ jeśli dobrze pamiętam, badanie nie ujawniło żadnych rzeczywistych korzyści dla TDD. Studium przypadku i tak było interesujące, a książka jest ogólnie jedną z najlepszych książek o oprogramowaniu, jakie ostatnio czytałem. Zawiera wiele studiów przypadków takich jak programowanie par, przegląd kodu itp.

Zdecydowanie sprawdź to: Udowodniono skuteczność TDD! Albo to jest?

... kiedy Phil Haack ogłosił, że badania wspierają skuteczność TDD, byłem bardziej niż trochę zainteresowany zobaczeniem, co faktycznie zawiera powiązany raport . Phil cytuje z streszczenia.

Stwierdziliśmy, że uczniowie, którzy jako pierwsi przystąpili do testów, napisali średnio więcej testów, a z kolei studenci, którzy napisali więcej testów, byli bardziej produktywni. Zauważyliśmy również, że minimalna jakość wzrosła liniowo wraz z liczbą testów programistów, niezależnie od zastosowanej strategii rozwoju.

Phil oczywiście przeczytał resztę raportu i przedstawia swoje ulubione utwory, które wydają się robić tak, jak sugeruje jego tytuł. Jedną z rzeczy, o które się martwię, gdy widzę rzeczy wspierające najnowsze i najlepsze praktyki tworzenia oprogramowania, jest jednak silna tendencja do stronniczości potwierdzania - szukania potwierdzenia aktualnych teorii i przeoczenia przeciw-wskaźników.

Będąc ciekawym typem, a ponieważ TDD jest czymś, na co uważam, aby sprawdzić, czy to coś, co może chciałbym przyjąć kiedyś, przeszedłem do raportu ...

... bez wątpienia testowanie najpierw prowadzi do większej liczby testów na jednostkę funkcjonalną. Pytanie brzmi, czy to jest cenne. Badanie to wydaje się wskazywać, że prawdopodobnie tak nie jest, przynajmniej jeśli jakość jest zamierzonym zyskiem. Ale nie jestem zaskoczony, że liczba testów nie odpowiada jakości, podobnie jak nie jestem zaskoczona, że ​​liczba wierszy kodu nie odpowiada wydajności.

Autor ma wiele dobrych argumentów na temat tego, że TDD nie jest aż tak skuteczne (imo pomimo hipnotyzowania na śmierć)

sprawdź, ile czasu ty i klient spędziliście ręcznie testując oprogramowanie; porównaj to z oszacowaniem, jak długo zajęłyby automatyczne testy w stylu TDD. Zrób różnicę

z mojego doświadczenia wynika, że ​​zautomatyzowane testy TDD są złote, ponieważ zapewniają ubezpieczenie i eliminują ogromne ilości ręcznych testów

jak zauważył Andres F, te korzyści można uzyskać jedynie dzięki automatycznym testom, niekoniecznie TDD - jednak TDD wymaga automatycznych testów, zamiast być późniejszym lub przyjemnym w użyciu

Zmuszenie do myślenia o testowaniu najpierw zmusza do myślenia o kwestiach związanych z jakością - takich jak modułowość, projektowanie interfejsu itp. - przed rozpoczęciem pisania kodu.

Osobiście uważam, że jedną z największych zalet TDD jest to, że pisanie testu najpierw zachowuje specyfikację tego, co kod ma do zrobienia na świeżo, gdy piszesz kod, a nie w pewnym sensie -as-you-code.

chcesz to uzasadnić: zasugeruj, aby zrobić to dla następnego projektu, a następnie uczyć się na nim. Jeśli okaże się, że działa świetnie dla ciebie, mam nadzieję, że będziesz nadal go używać, a jeśli zajęło to więcej czasu na wykonanie projektu i / lub poświęcenie całego czasu na pisanie testów zamiast kodowania, z pewnością zrzucisz go jako porażka.

Myślę, że prawdziwym rozwiązaniem jest (jak większość rzeczy) w połowie drogi, chcesz testów, ale nie chcesz, żeby testy były ważniejsze niż projekt.

(osobiście uważam, że TDD to moda, brzmi dobrze w teorii, ale w praktyce ... nie tak dobrze. Uważam, że testy integracyjne są o wiele ważniejsze, ale mogą to być właśnie takie złożone projekty, nad którymi pracuję).

Używam TDD od 2 lat i tam, gdzie wtedy pracowałem, wszyscy niechętnie korzystali z nich, w tym menedżerowie, jednak wkrótce okazało się to właściwe. Korzyści, które wkrótce zauważyliśmy, to:

• Odkrywanie błędów na wczesnym etapie.
• Pisanie lepszego kodu, nawet nie zdając sobie z tego sprawy.
• Twój kod jest teraz łatwiejszy w utrzymaniu, ponieważ ze względu na twoje testy wszystko jest w małych porcjach (mieliśmy funkcje, które były 300-400 linii) głupie. Teraz maksymalnie 30 i wszystkie osobno przetestowane.

Menedżerowie nie wiedzieliby, ponieważ wszyscy są zainteresowani jedną rzeczą: „Skończyłeś”. Ale narzekają, gdy oprogramowanie ciągle się psuje, nie zdając sobie z tego sprawy. Z dobrym zasięgiem i rozsądnymi testami. Nie chodzi o ilość, ale o jakość, którą naprawdę widać, gdy ktoś psuje funkcjonalność. Niestety, jest to trudne, jeśli jesteś sam. Miałem ten sam problem, ponieważ może być konieczna zmiana kodu, np. Klas podstawowych itp., Aby umożliwić testowanie części oprogramowania.

Podaję przykład. Chciałem wyśmiewać repozytorium, ale nie było interfejsu i muszę wstrzyknąć repozytorium do mojej warstwy usług, a zatem dodać / zmodyfikować konstruktor w całym sklepie, okazało się, że to wielka sprawa, ale w na koniec mam ponad 200 testów testujących tylko jeden obszar systemu i byli pod wrażeniem.

Zazwyczaj wykonuję następujące czynności:

• Trzymam moje najczystsze rzeczy bardzo krótko
• Tylko 1 aser. Brak rosyjskiej ruletki.
• Testuję scenariusz pozytywny - negatywny i wyjątkowy

Jeśli chodzi o studia przypadków, obawiam się, nie jestem pewien, czy je widziałem. Musisz zbudować swój projekt i stać się studium przypadku, może też być pod wrażeniem.

Mam nadzieję, że to pomoże