TDD / Testuje zbyt duże obciążenie / koszty utrzymania?

Słyszeliście to wiele razy od tych, którzy tak naprawdę nie rozumieją wartości testowania. Na początek jestem zwolennikiem zwinności i testowania ...

Niedawno miałem dyskusję na temat przeprowadzania TDD na przepisywaniu produktu, w którym obecny zespół nie ćwiczy testów jednostkowych na żadnym poziomie i prawdopodobnie nigdy nie słyszałem o technice wstrzykiwania zależności lub wzorcach / projektowaniu testów itp. (Nawet nie dostaniemy w celu wyczyszczenia kodu).

Teraz jestem w pełni odpowiedzialny za przepisanie tego produktu i powiedziano mi, że próba wykonania go w stylu TDD sprawi, że będzie to koszmar serwisowy i niemożliwy do utrzymania przez zespół. Co więcej, ponieważ jest to aplikacja typu front-end (nie oparta na sieci), dodawanie testów jest bezcelowe, ponieważ zmiany w dysku biznesowym (zmiany oznaczają oczywiście ulepszenia), testy staną się nieaktualne, a inni programiści projekt w przyszłości nie utrzyma ich i stanie się dla nich większym obciążeniem do naprawy itp.

Rozumiem, że TDD w zespole, który obecnie nie ma doświadczenia w testowaniu, nie brzmi dobrze, ale moim argumentem w tym przypadku jest to, że mogę nauczyć mojej praktyki otaczających mnie ludzi, ale ponadto wiem, że TDD LEPSZY oprogramowanie. Nawet jeśli miałbym produkować oprogramowanie przy użyciu TDD i przekazać wszystkie testy przekazania go zespołowi serwisowemu, to z pewnością byłoby to lepsze podejście niż całkowite niestosowanie TDD?

Zostałem zestrzelony, ponieważ wspominałem o robieniu TDD w większości projektów dla zespołu, który nigdy o tym nie słyszał. Myśl o „interfejsach” i dziwnie wyglądających konstruktorach DI odstrasza ich ...

Czy ktoś może mi pomóc w czymś, co zwykle jest bardzo krótką rozmową o próbie sprzedaży TDD i moim podejściu do ludzi? Zwykle mam bardzo krótkie okno kłótni przed upadkiem na kolana przed firmą / zespołem.

próba tego na wzór TDD sprawi, że będzie to koszmar serwisowy i niemożliwy do utrzymania przez zespół.

Nie możesz wygrać tego argumentu. Wymyślają to. Niestety, nie masz też żadnych faktów. Każdy podany przykład może zostać zakwestionowany.

Jedynym sposobem, aby to podkreślić, jest posiadanie kodu, którego utrzymanie jest tańsze.

Ponadto, ponieważ jest to aplikacja typu front-end (nie oparta na sieci), dodawanie testów jest bezcelowe,

Wszyscy to mówią. To może być również częściowo prawda. Jeśli aplikacja jest dość dobrze zaprojektowana, front-end robi bardzo niewiele.

Jednak jeśli aplikacja jest źle zaprojektowana, front-end robi zbyt wiele i jest trudny do przetestowania. Jest to problem projektowy, a nie problem testowy.

wraz ze zmianami popędu biznesowego (zmiany oznaczają oczywiście ulepszenia), testy staną się nieaktualne, inni programiści, którzy pojawią się w projekcie w przyszłości, nie będą ich utrzymywać i staną się dla nich większym obciążeniem do naprawy itp.

To ten sam argument, co powyżej.

Nie możesz wygrać sporu. Więc nie kłóc się.

„Jestem w pełni odpowiedzialny za przepisanie tego produktu”

W tym wypadku,

1. Mimo to dodaj testy. Ale stopniowo dodawaj testy w miarę postępów. Nie marnuj dużo czasu na pisanie testów jako pierwszych. Konwertuj trochę. Przetestuj trochę. Konwertuj trochę więcej. Przetestuj trochę więcej.

2. Używaj tych testów, dopóki ktoś nie odkryje, że testy działają, i pyta, dlaczego wszystko idzie tak dobrze.

Miałem ten sam argument przy przepisywaniu (od C ++ do Java) i po prostu użyłem testów, nawet jeśli mi to powiedziały.

Rozwijałem się bardzo szybko. Poprosiłem o konkretne przykłady poprawnych wyników, które przesłali w arkuszach kalkulacyjnych. Przekształciłem arkusze kalkulacyjne w unittest.TestCase (bez informowania ich) i używa ich do testowania.

Gdy testowałem akceptację użytkowników - i znaleziono błędy - poprosiłem tylko o arkusze kalkulacyjne z przykładami do przejrzenia, poprawienia i rozszerzenia w celu uwzględnienia problemów stwierdzonych podczas testu akceptacji. Przekształciłem poprawione arkusze kalkulacyjne w unittest.TestCase (bez informowania ich) i używa ich do testowania.

Nikt nie musi szczegółowo wiedzieć, dlaczego osiągasz sukces.

Po prostu odnieś sukces.

Możesz przekonać takie osoby (jeśli w ogóle) tylko z praktycznego punktu widzenia, demonstrując wartość TDD w prawdziwym życiu. Na przykład biorąc przykład niedawnego błędu i pokazując, jak zbudować test jednostkowy, który upewnia się, że błąd ten nigdy więcej się nie pojawi. A potem oczywiście napisz kilkanaście kolejnych testów jednostkowych, aby zapobiec pojawieniu się całej klasy podobnych błędów (a kto wie, może po drodze nawet odkryje kilka innych uśpionych błędów w kodzie).

Jeśli to nie zadziała w krótkim okresie, musisz popracować nad tym dłużej, po prostu wykonując TDD i starannie pisząc testy jednostkowe na swoich zadaniach. Następnie skompiluj kilka prostych statystyk po około pół roku (jeśli jest to możliwe w twoim środowisku), aby porównać częstości błędów w kodzie / zadaniach wykonywanych przez różnych programistów (anonimowych, aby zapobiec alienacji członków twojej drużyny). Jeśli możesz zauważyć, że w twoim kodzie znaleziono znacznie mniej błędów niż w innych, możesz mieć mocną stronę, aby sprzedawać zarówno kierownictwu, jak i innym programistom.

Musisz być praktyczny w tych sprawach, TDD to dobra rzecz w teorii, ale jeśli nie aktualizujesz testów dla wszystkiego, co zostanie dodane, nie ma to sensu - nikt nie chce uruchamiać testu, który zgłasza uszkodzenie kod, gdy jest to test, który nie został zaktualizowany! W rezultacie ich wykonanie może być zbyt kosztowne - nie będziesz jedynym programistą pracującym nad tym kodem.

Klient ma zespół testowy ... no cóż, nie ma problemu z przeniesieniem ciężaru testowania z programisty na testerów - przecież oni po to są i jeśli znajdą błędy w swoich testach (może mają dużo zautomatyzowane narzędzia testujące), więc nie ma sensu pisać testów jednostkowych na swoim poziomie. Znalezienie błędów zajmie trochę więcej czasu, ale znajdą te irytujące błędy „integracji”, których nie przeprowadziłyby twoje testy.

Możliwe, że dlatego nie dbają o testy jednostkowe.

Wreszcie TDD to nowa rzecz, kiedy byłem chłopcem, którego nigdy nie testowaliśmy i pisaliśmy działający kod. Testy jednostkowe sprawiają, że niektórzy ludzie czują się ciepło i rozmazani, ale absolutnie nie jest to wymagane do poprawnego kodu.

PS. Widzę inne twoje pytanie, w którym krytykujesz warstwy abstrakcji, a tutaj krytykujesz brak konstruktorów DI! Podejmij decyzję :)

Ponieważ wszystko zmienia się tak szybko, jak to ułożysz, wyjaśnij im, że zostanie użyte do testowania regresji. Co pozwoli zaoszczędzić wielu problemów, gdy zostaną wprowadzone nowe błędy, ponieważ ktoś złamał linię kodu napisaną 10 lat temu, aby rozwiązać problem, który występuje 1 na każde 10 000 000 wykonań określonej funkcji, która jest wywoływana tylko wtedy, gdy zegar systemowy jest włączony klient ma różnicę większą niż 3 minuty niż zegar systemowy serwera. Zapytaj ich, ilu klientów mogą sobie pozwolić na utratę z powodu błędnego oprogramowania.

Zwróć uwagę, że znalezienie błędu podczas programowania kosztuje X, podczas testowania 10X, a po wdrożeniu 100X. Sprawdź, czy pozwolą one przynajmniej przeprowadzić test pilotażowy, w którym wdrażasz TDD w określonym module, a następnie porównaj z innymi modułami, gdy są one opracowywane, testowane, wdrażane i obsługiwane. Biorąc pod uwagę odpowiednie dane, powinieneś być w stanie wykazać, jak mniej wysiłku włożono w tworzenie kodu w module TDD. Powodzenia.

Tak, utrzymanie testów jest ciężarem. Aktualizowanie ich, aktualizowanie danych testowych: wszystko to pochłania Twój czas.

Alternatywa - ręczne testowanie rzeczy, naprawianie błędów, które się regresują, niemożność stwierdzenia w ciągu kilku sekund, że Twój kod działa - kosztuje znacznie więcej.

Cóż, próba jest ciężarem, ale dobrze jest nieść. Lepiej jest wykonać trochę pracy z góry, co pozwoliłoby zaoszczędzić sporo czasu w przypadku problemów z produkcją lub podczas migracji. Zawsze będę chciał poddać się próbie, mimo że jest to niewielki ciężar, ale chcę go ponieść.