Czy istnieją obszary, w których TDD zapewnia wysoki zwrot z inwestycji i inne obszary, w których ROI jest tak niski, że nie warto go śledzić? [Zamknięte]

Rozwój oparty na testach. Rozumiem, podoba mi się.

Ale testy pisemne wymagają narzutu. Tak więc TDD powinno być stosowane uniwersalnie w całej bazie kodu, czy też istnieją obszary, w których TDD zapewnia wysoki ROI oraz inne obszary, w których ROI jest tak niski, że nie warto go śledzić.

Powiedziałbym, że unikaj TDD w miejscach, w których kod może się bardzo zmienić strukturalnie. To znaczy, że wspaniale jest mieć stos testów dla metody, której podpis zmienia się rzadko, ale jest częściej refaktoryzowany wewnętrznie, ale trudno jest naprawiać testy za każdym razem, gdy bardzo niestabilny interfejs zmienia się drastycznie.

Aplikacje, nad którymi ostatnio pracuję, to oparte na danych aplikacje internetowe oparte na architekturze Gui-> Presenter-> BusinessLogic-> Data Access Layer. Moja warstwa dostępu do danych jest testowana jak niczyja firma. Warstwa logiki biznesowej jest dość dobrze przetestowana. Prezenterzy są testowani tylko w bardziej stabilnych obszarach, a GUI, które zmienia się co godzinę, prawie nie ma testów.

Sugeruję napisanie pełnego zestawu testów w obszarach, w których jest to rozsądne i praktyczne. W mniej praktycznych obszarach pisz kontrole poczytalności.

Z mojego doświadczenia wynika, że ​​narzut związany z pełnym zestawem przypadków testowych jest z pewnością tego wart w większości przypadków, ale realistycznie pokrycie kodu ma coraz mniejsze zyski. W pewnym momencie pisanie kolejnych testów w celu zwiększenia zasięgu kodu nie ma sensu.

Na przykład, w zależności od języka / technologii, testowanie interfejsu użytkownika może nie być praktyczne, a nawet wykonalne. Wiele testów prawdopodobnie będzie polegało na tym, co widzi użytkownik i nie może być zautomatyzowane. Jak przetestowałbyś, że metoda generowania captcha tworzy obraz, który może być odczytany na przykład przez człowieka?

Jeśli napisanie pełnego zestawu testów zajmie ci trzy dni, prawdopodobieństwo wystąpienia błędu w tym elemencie jest bardzo niskie, a sama funkcja zajmuje tylko pół godziny, więc powinieneś dobrze przemyśleć o tym, czy ten czas jest tego wart. Może samo napisanie podstawowej kontroli poczytalności dla tej funkcji zapewniłoby wartość?

Moja ogólna rada jest taka, że ​​powinieneś w pełni przetestować komponenty tam, gdzie testy można stosunkowo łatwo napisać. Jednak jeśli jest to obszar, który jest bardzo trudny do przetestowania, narysuj linię w piasku i napisz testy, które przetestują obszar na wyższym poziomie, zamiast go w pełni przetestować.

W poprzednim przykładzie captcha może napisać testy, które sprawdzają, czy obraz o prawidłowym rozmiarze i formacie jest zwracany i czy nie są zgłaszane żadne wyjątki. To daje pewien poziom pewności bez przesadzania.

Dla mnie TDD nie jest narzutem. Tak właśnie piszę kod. Dlaczego mówisz, że test pisemny jest „narzutem”? To tylko część procesu. Moim punktem widzenia jest to, że debugowanie jest narzutem i jest to działanie, które zasadniczo przestałem wykonywać, kiedy zacząłem TDD. Przed TDD debugowanie było integralną częścią mojego procesu pisania oprogramowania.

Myślę, że rezygnacja z debugowania podczas pisania testów jest bardzo dobrą okazją.

Jednym z miejsc, w których TDD jest naprawdę do kitu, jest testowanie widoków w aplikacji MVC.

Ponieważ testujesz funkcję, która zwraca gruby ciąg HTML, utknąłeś podczas analizowania HTML, aby sprawdzić, czy wszystko się udało. Co więcej, może stać się koszmarem utrzymania. Pewnego dnia, gdy przesuwasz pole wyboru i kaboom, twój test jest zepsuty.

Lubię wiele TDD podczas wielu testów, ale nie jest to jedyne narzędzie w pasku programisty.