Pracuję w dużej firmie, ale w dwuosobowym zespole opracowującym aplikacje LOB na komputery. Od dłuższego czasu badam TDD i chociaż łatwo jest dostrzec jego zalety w przypadku większych aplikacji, trudno mi jest usprawiedliwić czas rozpoczęcia korzystania z TDD na skalę naszych aplikacji.

Rozumiem jego zalety w automatyzacji testów, poprawie łatwości konserwacji itp., Ale na naszą skalę pisanie nawet podstawowych testów jednostkowych dla wszystkich naszych komponentów może z łatwością podwoić czas programowania. Ponieważ jesteśmy już zagrożeni ekstremalnymi terminami, nie jestem pewien, jaki kierunek obrać. Podczas gdy inne praktyki, takie jak zwinny rozwój iteracyjny, są doskonałe, jestem trochę rozdarty kompromisami w zakresie wydajności TDD w małym zespole.

Czy zalety TDD są warte dodatkowego czasu na rozwój w małych zespołach o bardzo napiętych harmonogramach?

Brzydka prawda jest taka, że początkowo spowolni cię . Przyspieszenie każdego nowego procesu lub praktyki zajmuje trochę czasu. Z mojego doświadczenia wynika, że ​​TDD nie wypłaca się przy początkowej implementacji tak bardzo jak przy konserwacji, naprawianiu błędów i rozszerzaniu. Wiem, że dla innych istnieje natychmiastowa wypłata, więc będzie ona zależeć od bieżącego stylu kodowania każdej osoby.

Chociaż jestem wielkim zwolennikiem TDD (wprowadziłem go do mojej obecnej pracy) , myślę, że musisz mieć trochę czasu na oddychanie (terminy / harmonogramy) , aby poznać i zrozumieć praktykę.

Im mniejszy zespół, tym szybciej możesz skorzystać z TDD. Widziałem tę wypłatę w rozmiarze od 6 do 3.

Dodatkowy czas rozwoju, o którym mówisz, może być iluzją .

To, co odróżnia TDD od standardowych testów jednostkowych, polega na tym, że nie służy ono tylko do wykonywania testów.

TDD is a new way of developing software. To jeden z najlepszych sposobów, jakie znam.

Dlatego nie ma to związku z rozmiarem twojego projektu. Wyciągniesz korzyści z pierwszego wiersza kodu .

• zmusi cię do uporządkowania kodu w sposób łatwiejszy do utrzymania i ponownego użycia. Steruje projektem twojego oprogramowania.
• sprawi, że refaktoryzacja będzie szybka, bezpieczna i przyjemna.
• pomaga pisać mniejsze fragmenty funkcjonalności, co znacznie ułatwia realizację zadań.
• zwykle powoduje to, że zadanie debugowania jest rzadsze.

powszechne nieporozumienie, wykrzyczę to:

TESTY W TDD SĄ DLA CECH

EOM.

Edycja: pozwól mi rozwinąć: „pisanie ... testów jednostkowych dla wszystkich lub naszych komponentów” to testy jednostkowe , a nie TDD. Rutynowo używam TDD w zespołach jednoosobowych z wielkim sukcesem; wypłata jest nadzwyczajna.

Jest świetna książka na temat TDD, Sztuka testowania jednostek ( oficjalna strona ), która ma swoje przykłady w .net z wersją java na temat prac. Dobrą stroną jest to, że są całe rozdziały dotyczące takich zagadnień, jak „Integracja testów jednostkowych w organizacji” - Rozdział 8 i „Praca ze starszym kodem” - Rozdział 9. Chociaż nie jestem ekspertem w tej dziedzinie (jeszcze :-)) , na podstawie mojego doświadczenia uważam, że to dobry punkt wyjścia.

Aby uzyskać odpowiedzi, musisz odpowiedzieć na kilka pytań:

1. Ile czasu spędzasz po naprawieniu błędu w kodzie? Jeśli potrafisz to określić ilościowo, może się okazać, że jest on równy lub nawet przekracza „dodatkowy” czas, który zajęłoby Ci napisanie testu, który pomógłby uniknąć tych błędów.

2. Jak często pozornie prosta edycja w celu zmiany kodu lub dodania nowej funkcji psuje coś, co najwyraźniej nie ma związku? Ponownie przy dobrym pokryciu testowym można je zmniejszyć.

Nawet jeśli nie potrafisz podać dokładnych liczb, powinieneś być w stanie wykazać, że i tak spędzasz ten czas, abyś mógł równie dobrze wydać go „z góry” i (miejmy nadzieję) skończyć na znacznie bardziej stabilnym produkcie.

Kiedy ludzie mówią mi o rozpoczęciu testowania w swoim zespole, zawsze najpierw sprawdzam, jak będą przeprowadzane testy. Często drużyny nie mają ciągłej rozbudowy. Jeśli masz ograniczone zasoby, sugeruję, że skonfigurowanie serwera CI jest warunkiem wstępnym rozpoczęcia poważnych prób testowania.

Gdy już to skonfigurujesz, zacznij ćwiczyć TDD. Pamiętaj, że jeśli system nie został opracowany z myślą o testowaniu, możesz mieć trudności z przetestowaniem istniejącego kodu i jego restrukturyzacja będzie kosztowna.

Zacznij od szukania łatwych miejsc do rozpoczęcia od TDD - nowych klas lub modułów, z kilkoma zależnościami. Klasy narzędzi i struktury danych to często dobre rzeczy na początek.

Sprawdź, jak zmienia się sposób myślenia o kodzie, zwróć uwagę na to, o ile lepszy jest tworzony kod i na ile jesteś bardziej pewny co do tego kodu.

Wiem, że tak naprawdę nie odpowiedziałem na to pytanie, ale sądzę, że mam na myśli to, że powinieneś być w stanie to wszystko zrobić bez ogromnych dodatkowych kosztów. Pracując nad pierwszymi przykładami, lepiej zrozumiesz zalety swojego projektu.

Podsumowując - wolniejszy rozwój, ale mało wad, a więc o wiele mniej czasu na naprawianie błędów.

Tutaj myślę, że rozwój oparty na zachowaniach wykazuje natychmiastowe korzyści, ale nie jestem pewien, czy rozwój oparty na testach.

W rozwoju opartym na zachowaniu podchodzisz do biletów w inny sposób: siadasz z przedsiębiorcą i współpracujesz z nim, aby określić zachowania, które powinna mieć ta część funkcjonalności. Opisuję to we wpisie na moim blogu (tytuł posta: Pisanie zachowań ).

Siadanie z przedsiębiorcą lub kimkolwiek, kto pomoże Tobie i nim lepiej zrozumieć, co system musi zrobić, aby wszyscy byli zadowoleni z tej funkcji. Co należy zrobić, aby zostać zaakceptowanym przez proces kontroli jakości, który masz na miejscu.

Zdefiniowanie kryteriów testowych, a następnie zapisanie tych kryteriów testowych w zautomatyzowanym pakiecie testowym, powinno zmniejszyć ilość otrzymywanych tam iz powrotem: ktoś twierdzi, że funkcjonalność jest zepsuta, ponieważ coś przegapiłeś (albo dlatego, że coś legalnie przegapiłeś, albo dlatego, że nigdy ci nie powiedziało) ty o tym).

Może to również pomóc w postrzeganiu twojego zespołu przez innych: jeśli usiądziesz i określisz, co należy zrobić w systemie, możesz przejść od „idiotów, którzy wszystko nadzorują i spędzają czas na rzeczach, o które nie prosiliśmy”, „inteligentni ludzie, którzy wymyślają przydatne funkcje”.

TL; DR: Rozwój oparty na zachowaniach może szybko wykazywać ulepszenia, ponieważ koncentruje się na „kliencie”. Wydaje mi się, że Test Driven Development dotyczy testowania wewnętrznych części kodu, na których „nikt” nie dba i daje mniej oczywiste korzyści biznesowe. (Rozwój napędzany zachowaniem ma natychmiastową, bezpośrednią zmianę: inżynierowie nagle mają dużo więcej czasu na kontakt z „klientem” lub analitykiem biznesowym, aby spróbować to zrobić dobrze - co należy postrzegać jako dobrą rzecz. ”Och , mają spotkanie na temat Funkcji X, co oznacza postęp na tym froncie! ”)