Chcę przedstawić koncepcję testów jednostkowych (i testów ogólnie) moim współpracownikom; w tej chwili nie ma żadnych testów, a rzeczy są testowane poprzez wykonywanie zadań za pośrednictwem interfejsu użytkownika, aby zobaczyć pożądany wynik. Jak można sobie wyobrazić, kod jest bardzo ściśle powiązany z dokładną implementacją - nawet w wyniku tego kod, który powinien należeć do klasy i być ponownie wykorzystywany w całym systemie, jest kopiowany i wklejany w różnych metodach.

Ze względu na zmienione wymagania zostałem poproszony o zmodyfikowanie modułu, który wcześniej napisałem i który jest dość luźno powiązany (nie tak bardzo, jak bym chciał, ale najlepiej, jak mogę, bez konieczności wprowadzania wielu innych koncepcji). Zdecydowałem się dołączyć pakiet testów jednostkowych do mojego poprawionego kodu, aby „udowodnić”, że działa zgodnie z oczekiwaniami i zademonstrować, jak działa testowanie; Nie przestrzegam prawdziwego TDD, ponieważ część kodu jest już napisana, ale mam nadzieję, że zastosuję się do niektórych koncepcji TDD dla nowego kodu, który będę musiał utworzyć.

Teraz, nieuchronnie, jestem pewien, że zostaniesz zapytany, dlaczego napisanie kodu zajmuje mi więcej niż dzień lub dwa, skoro części tego, z czym będę wchodził w interakcje, już istnieją w systemie (choć bez żadnych testów i bardzo ściśle sprzężony), a kiedy sprawdzę kod, zostaniesz zapytany, co to za projekt „Testy”. Potrafię wyjaśnić podstawy testowania, ale nie potrafię wyjaśnić rzeczywistych korzyści w sposób zrozumiały dla innych (ponieważ ich zdaniem testowanie wymaga samodzielnego uruchomienia aplikacji, ponieważ często rzeczywisty interfejs użytkownika ma znaczenie przy określaniu, czy funkcja „działa” " albo nie). Nie rozumieją idei luźnego sprzężenia (wyraźnie widoczne przez fakt, że nic nie jest luźno sprzężone; nie ma nawet żadnych interfejsów poza kodem, który napisałem), więc próba wykorzystania tego jako korzyści prawdopodobnie przyniosłaby mi „Huh?” taki wygląd i znów nie mogę być tak swobodny, jak bym tego chciał, bez konieczności przerabiania kilku istniejących modułów i prawdopodobnie wprowadzenia pewnego rodzaju kontenera IoC, który byłby postrzegany jako marnowanie czasu, a nie „programowanie”.

Czy ktoś ma jakieś sugestie, w jaki sposób mogę wskazać ten kod i powiedzieć „Powinniśmy zacząć tworzyć testy jednostkowe”, nie odchodząc jako protekcjonalne (np. „Pisanie testów zmusza cię do napisania dobrego kodu”. z wyjątkiem tego, że mój jest zły ), czy też nie sprawia, że ​​wydaje się to stratą czasu, która nie wnosi żadnej realnej wartości?

Chcę przedstawić koncepcję testów jednostkowych (i testów ogólnie) moim współpracownikom

Myślę, że lepiej zacząć od strony praktycznej, a nie konceptualnej. Oczywiście, jeśli podczas swobodnej dyskusji okaże się, że Twoi współpracownicy i / lub kierownictwo są zainteresowani, aby usłyszeć o testach jednostkowych, tym lepiej - możesz przejrzeć konkretne doświadczenia / dowody z Internetu, zorganizować krótkie szkolenie itp. Jednak z tego, co opisujesz, wygląda na to, że twoi koledzy z drużyny nie są zbyt otwarci na ten dziwny nowy pomysł.

W takiej sytuacji zacząłem pisać moje małe testy jednostkowe, nie próbując wyjaśnić nikomu za dużo. Dodaj kilka z nich za każdym razem, gdy zmieniam kod, nie próbując całkowicie obejmować całego kodu (co zajęłoby nadmiernie dużo czasu). Idealnie, jeśli uda mi się zachować równowagę, zanim zauważą, że piszę testy jednostkowe, mogę już mieć znaczny pakiet testów i pewne konkretne wyniki do pokazania (np. „W tym przypadku testowym udało mi się złapać błąd wprowadzone przez zeszłotygodniową zmianę, która w innym przypadku przeszedłaby na kontrolę jakości / produkcję ”). To udowodni wartość testów każdemu poważnemu deweloperowi.

Po tym jestem w stanie zacząć wyjaśniać długoterminowe korzyści z testów jednostkowych

• dowodzi, że kod działa - zawsze, wszędzie, natychmiast i automatycznie, co z kolei
• daje pewność refaktorowi, co skutkuje ulepszoną konstrukcją i lepszą konserwacją,
• a jeśli coś się zepsuje, testy jednostkowe dają (prawie) natychmiastową informację zwrotną, w przeciwieństwie do kilku dni lub tygodniowych opóźnień, jeśli błąd zostanie wykryty przez osobny dział kontroli jakości. Co zwykle pozwala naprawić błąd w ciągu kilku sekund zamiast debugowania przez kilka godzin / dni w kodzie, który już dawno zniknął z pamięci krótkotrwałej.

Zobacz także ten powiązany wątek: Automatyczne testy jednostkowe, testy integracyjne lub testy akceptacyjne .

I wcześniejszy z SO: Co to jest testowanie jednostkowe?

Ponownie czynnik bez strachu

Z nieco innej perspektywy, TDD pozwala „przefakturować bez strachu”, a jest to kluczowa korzyść, którą możesz sprzedać swojemu zespołowi. Uniemożliwia programistom mówienie do siebie:

• „Nie chcę dotykać tego kodu, ponieważ obawiam się, że go złamę”
• „Nie chcę pisać nowych funkcji w celu pof tego kodu, ponieważ nie wiem, jak to działa”
• „Potajemnie boję się tego kodu”

Mógłbym harfować na więcej, ale jest to dobrze zakryty grunt, taki jak wujek Bob na TDD i Martin Fowler na TDD .

Zależności

Och, dodam jeszcze jedną rzecz. Pokaże im, w jaki sposób TDD wymusza dobry projekt, który umożliwia czyste radzenie sobie z zależnościami.

Bob: „Och c% ^ p! Szefowie po prostu zmusili nas wszystkich do korzystania z MS SQL Server 2008” Jane: „W porządku, szkody zostały zminimalizowane, ponieważ wyodrębniliśmy nasze źródło danych i nasze klasy DAO, cieszę się, że TDD zachęciło nas tą ścieżką ”.

Pracując nad kodem źródłowym, który nie ma automatycznych testów, musimy pracować z dużą ostrożnością i potrzebujemy więcej recenzji, aby mieć pewność, że wprowadzane przez nas zmiany nie psują żadnej z istniejących funkcji.

Gdy mamy dobre zautomatyzowane przypadki testowe, konsekwencjami będzie szybszy, pewniejszy i nieustraszony rozwój (może to być naprawa błędów, ulepszanie lub zmiana faktury).

Zrobić matematykę

• t _mt = czas wymagany do ręcznego przetestowania wszystkiego, na co możesz wpłynąć
• t _wt = czas wymagany do napisania testów

• k = ile razy będziesz prawdopodobnie musiał wszystko przetestować przed wydaniem nowego kodu

  jeśli (t _wt <t _mt ) lub (t _wt <(k * t _mt )) to nie ma wątpliwości: pisanie testów przyspieszy rozwój.

w przeciwnym razie spójrz na stosunek (t _wt / (k * t _mt )). Jeśli jest to bardzo duża liczba, poczekaj na kolejną okazję; w innym przypadku uzasadniają korzyści z testowania regresji.

Uwaga: w tym miejscu sugeruję, aby testować tylko funkcje, a nie jednostki - o wiele łatwiej to uzasadnić i zrozumieć, i prawdopodobnie mniej pracy przy wyższej wartości niż zwykłe testy jednostkowe podczas refaktoryzacji.

Uwaga 2: czas potrzebny na uruchomienie testów nie ma znaczenia , ponieważ są one zautomatyzowane. Podczas testów możesz zrobić coś innego produktywnego, chyba że testy trwają tak długo, że nie dotrzymasz terminu. Co jest rzadkie.

Jedna z propozycji, jeśli jesteś sklep Microsoft: znaleźć jakąś dokumentację na MSDN zalecające testów jednostkowych lub luźne couping jako najlepszej praktyki (jestem pewien, że istnieje wiele instancji tego ) i wskaż na nią, jeśli istnieją konflikty.

Może to zabrzmieć jak grubiański sposób robienia rzeczy, ale odkryłem, że użycie terminu „najlepsza praktyka” zabierze cię daleko, szczególnie w zarządzaniu.

Jak zawsze polecam, jeśli znasz dobrą praktykę, najlepszym sposobem na jej delikatne wprowadzenie do środowiska byłoby oczywiście rozpoczęcie jej samemu, a następnie gdzieś po drodze niektórzy z Twoich współpracowników zobaczą korzyści i Podnieś to.

Kluczowym słowem jest tutaj ewolucja, a nie rewolucja.