Jak motywować współpracowników do pisania testów jednostkowych? [Zamknięte]

Pracujemy nad dużym produktem, który jest produkowany od około 5 lat. Baza kodów działa ... eee ... działa. Niezbyt dobrze, ale działa. Nowe funkcje są wprowadzane do produkcji i testowane z niewielką kontrolą jakości. Błędy zostały naprawione itp. Ale nikt oprócz mnie nie pisze testów jednostkowych. Nikt nie korzysta z mocy „śledzenia” błędów, pisząc testy jednostkowe, aby upewnić się, że ten specjalny błąd (przypadek testowy) nigdy się nie powtórzy.

Rozmawiałem z zarządem. Rozmawiałem z programistami. Rozmawiałem ze wszystkimi w całej firmie. Wszyscy mówią: „Tak, musimy napisać więcej testów jednostkowych!” To było około rok temu. Od tego czasu wymusiłem wprowadzenie przeglądu kodu przed zatwierdzeniem ( Gerrit ) i ciągłej integracji ( Jenkins ).

Odbyłem kilka spotkań na temat testów jednostkowych, a także pokazałem zalety pisania testów jednostkowych. Ale nikt nie wydaje się zainteresowany.

P1: Jak zmotywować moich współpracowników do napisania testów jednostkowych?

Q2: Jak mogę zmotywować się do przestrzegania standardów jakości mojego osobistego kodu? (Czasami jest to naprawdę frustrujące!)

PS: Niektóre frustrujące fakty (osiągnięte w ciągu 1 roku):

• Łączna liczba testów jednostkowych: 1693
• Łącznie „przykładowe testy jednostkowe”: około 50
• Sporządzono przeze mnie: 1521

Edycja: Czy oczekuję zbyt wiele? To moje pierwsze miejsce pracy i staram się dać z siebie wszystko.

Edycja 2: Na podstawie wszystkich odpowiedzi stworzyłem sobie małą listę kontrolną. Rozmawiałem z dwoma deweloperami na osobności i rozmawialiśmy dobrze.

Jeden z nich powiedział mi, jak powiedział Telastyn , że jest naprawdę niewygodny w testach jednostkowych. Powiedział, że chciałby być „bardziej profesjonalny”, ale potrzebuje kickstartu. Powiedział także, że nasze spotkanie w sprawie testów jednostkowych ze wszystkimi programistami (około 9–11) było dobre, ale było zbyt tłoczno. Meh Niektórzy krytycy dla mnie, ale nauczę się z tego. (patrz odpowiedzi poniżej dotyczące spotkań kata TDD!)

Drugi powiedział, że nie jest zainteresowany pisaniem testów jednostkowych. Uważa, że ​​jego praca wystarcza na jego pensję. Nie chce wkładać większego wysiłku. Byłem całkiem zaniemówiony. Typowy „pracownik” 9–5.

W przyszłym tygodniu będę rozmawiać z innymi programistami.

Dziękujemy za wspaniałe odpowiedzi (jak dotąd!) I wsparcie. Bardzo to doceniam! Dużo się nauczyłem, dziękuję bardzo!

Zauważyłem, że mówienie o TDD prawie nie działa. Ludzie lubią widzieć surowe wyniki . Mówienie, że „testy pisemne skracają czas programowania” jest najprawdopodobniej prawdziwe, ale może nie wystarczyć, aby przekonać kogokolwiek.

Byłem w podobnej sytuacji (cóż, nie tak źle jak Twoja) i to trochę rozwiązało się, gdy ludzie zaczęli pracować nad moim kodem (uwaga: mój kod był testowany jednostkowo, inni nie tak bardzo). Kiedy coś przestało działać, naturalnym śledztwem po lokalnym śledztwie było pytanie mnie, co może być przyczyną . Potem usiedliśmy, przeprowadziliśmy testy jednostkowe i zobaczyliśmy, co się stało. Jeśli testy przebiegały pomyślnie, przez większość czasu problemy występowały w nowym, nieprzetestowanym kodzie. Jeśli nie, testy zwykle były w stanie wykryć problem (lub przynajmniej wskazać nam właściwy kierunek). Naprawiliśmy błąd, testy były znowu uruchomione, wszyscy byli zadowoleni.

Krótko mówiąc, zdarzyło się kilka takich sytuacji i 2 kolejnych programistów zostało entuzjastami TDD / testowania (jest jeszcze kilka do zrobienia, ale wygląda to obiecująco).

Co do porady, możesz spróbować z kata TDD; proste zadanie do wdrożenia przy użyciu pierwszego testu, w przeciwieństwie do braku testów . W zależności od złożoności zadania podejście inne niż testowe powinno zwykle być wolniejsze, szczególnie przy wymaganych wymaganych przyrostowych zmianach:

• Kalkulator strun Roy'a
• Bank OCR

Edycja : Komentarz OP uświadomił mi, że ma do dyspozycji jeszcze silniejszy argument - regresja czyli powrót błędów . Tego rodzaju sytuacje są idealnymi przykładami pokazującymi, jak korzystne mogą być testy jednostkowe. Ludzie lubią liczby - tak jak powiedziałem, powiedzenie „testowanie jednostkowe jest dobre” może nie być przekonujące, ale z pewnością uporządkowanie danych jak poniżej:

• czas poświęcony na wdrożenie funkcji (nie napisano żadnych testów; zakładam, że zdarzało się to często, więc znalezienie takiego przykładu powinno być stosunkowo łatwe)
• szacowany czas na wdrożenie funkcji z TDD (lub nawet testy po podejściu; nie ma znaczenia - ważna jest obecność testów jednostkowych)
• czas spędzony na rozwiązywaniu błędu na nietestowanym kontra testowanym kodzie

Jedna rzecz, o której należy cię ostrzec (ta migliwość jest oczywista, ale warto zauważyć): stronniczość wyniku - upewnij się, że nie wybierasz przykładu, w którym jedynym sposobem wykrycia błędu w teście było napisanie testu dla tego błędu. Zwykle nikt nie wie, że błąd wystąpi z góry, ale kuszące jest powiedzenie „człowieku, ten błąd byłby trywialny, gdybyśmy przetestowali X” - łatwo jest znaleźć zwycięską taktykę dla wojny po jej zakończeniu.

Wynik tych przykładów powinien być prostym pytaniem - jeśli mógłbyś spędzić x godzin na rozwijaniu funkcji Y, dlaczego miałbyś nalegać na zrobienie tego w 2x ?

Najpierw musisz wiedzieć, dlaczego nie piszą testów.

Często powodem są napięte harmonogramy twórców, ale mówisz, że tego nie masz.

Kolejnym powodem jest to, że przy dużej istniejącej, nieprzetestowanej bazie kodu pisanie testów wydaje się być przytłaczające - niekończąca się praca (jak pranie i mniej więcej tak ekscytujące). Więc ludzka natura uważa, że ​​to zbyt wiele, aby stawić temu czoła, więc pominę to.

Innym powodem może być to, że choć uważają, że testy są dobrym pomysłem, nie są pewni, jak zacząć je pisać, zwłaszcza jeśli nigdy nie pracowali nigdzie, gdzie je napisali.

Inną silną możliwością jest to, że tak naprawdę nie widzą żadnej wartości dla większej ilości pracy, mimo że szczerze to pomogli.

Jak radzisz sobie z różnymi przyczynami?

Powód pierwszy jest prosty, pokaż im przykład, w jaki sposób oszczędza czas programowania.

Powód drugi - pokaż im, ile testów napisałeś w ciągu roku i jaki procent podstawy kodu obejmuje. Wykonaj matematykę, aby pokazać, ile dodatkowych testów mogliby przeprowadzić w tym czasie w przyszłym roku, gdyby to zrobili. Kiedy widzą, że małe postępy na co dzień naprawdę się sumują, cały pomysł nie jest tak przytłaczający. Jeśli możesz wyciągnąć dane z systemu, pokaż im, ile błędów było powtarzającymi się błędami w nieprzetestowanych częściach kodu i ile powtarzających się błędów pojawia się w kodzie podczas testów jednostkowych.

Powód 3 to trening, a nie tylko pokazywanie. Niech piszą testy w klasie szkoleniowej.

Powód 4, to sedno sprawy. Najpierw wybierz punkt bólu, jeden z tych błędów, które powróciły wiele razy. Kiedy to nastąpi, nadszedł czas, aby zasugerować kierownictwu, że gdyby przeprowadzili testy jednostkowe tego przedmiotu, nie wracałby jak zły grosz.

Innym sposobem rozwiązania problemu 4 jest włączenie zarządzania przez proces, a kod nie przechodzi przeglądu kodu, chyba że testy również przejdą przegląd kodu. Najlepiej podejdź do nich, czyniąc z tego polisę zaraz po jednym z tych punktów bólu lub najlepiej po kilku w ciągu kilku dni.

Wszyscy lubimy myśleć, że jako programiści zarządzamy samodzielnie (LOL), ale ambitni będą dbać o to, na co zwraca uwagę zarządzanie, na których powinni się troszczyć, a profesjonaliści, którzy naprawdę zarządzają samodzielnie, już piszą testy. Jeśli nie zależy im na tym, by być profesjonalistami i postępować zgodnie z najlepszymi praktykami, ponieważ ulepszają produkt, lub zależy im na imponowaniu menedżerom, aby awansowali (lub nie zostali zwolnieni), możesz rozważyć, czy jest to właściwe miejsce dla ciebie. Jeśli nie możesz zmusić kadry kierowniczej do dbania o najlepsze praktyki, to będziesz walczył pod górę przez cały czas, możesz ocenić, czy jest to właściwa kultura korporacyjna dla Ciebie. Chociaż każde miejsce pracy ma swoje problemy (a ucieczka nie zawsze jest odpowiedzią), to miejsce nie wydaje się pasować do Twojego poziomu profesjonalizmu.

Chciałbym rozpocząć poprzez wykazanie korzyści TDD. Spróbuj pokazać zalety testowania jednostkowego.

Jak zwykli ludzie, twórcy motywowani są korzyściami. Nie chcą robić rzeczy, które po prostu tworzą więcej pracy. Testowanie jednostkowe oznacza mniej pracy . Oznacza to więcej spotkań z przyjaciółmi. Oznacza to więcej zabawy, ponieważ nie musisz spędzać każdej nocy na kodowaniu do 23:00. Oznacza to, że bardziej jedziesz na wakacje w spokoju.

Jedną z największych zalet jest to, że TDD można byłaby program do lepszego projektowania lub po prostu zmienić nazwę czegoś ... i tak długo, jak projekt nie łamie testów, można mieć pewność 100%, że zmiana nic nie zepsułem.

Innym doskonałym przykładem TDD jest tworzenie testów jednostkowych starszego kodu . Byłby to jeden z najlepszych sposobów na rozpoczęcie refaktoryzacji zła. Na dłuższą metę posłuży to poprawie znajomości bazy kodu, zrozumieniu jego mocnych i słabych stron, dostrzeżeniu zakodowanej logiki biznesowej w kodzie i zapewni dobry początek poprawy jakości w przyszłości!

Dobre referencje do dalszego czytania:

• Dlaczego warto pisać testy jednostkowe
• Widoczność motywacji i testy jednostkowe
• Sztuka testowania jednostkowego według Roy Osherove

http://blog.jtimothyking.com/2006/07/11/twelve-benefits-of-writing-unit-tests-first

Myślę, że jakiś czas temu dodałem do zakładek ten link z artykułu Jeffa Atwooda [edytuj: tak, oto jest] . Stare, ale istotne. Ze względu na te i inne korzyści, które niewątpliwie zostaną przedstawione w innych odpowiedziach, programiści powinni być w stanie zmotywować się ! Pozwoli im to na bardziej wydajną pracę, a tym samym ułatwi ich pracę. Kto tego nie chce?

Jeśli chodzi o twoje drugie pytanie: twoje poczucie własności i duma ze standardów jakości kodu powinny cię wspierać . Zastanów się, co chcesz osiągnąć, mając takie standardy i kto z nich korzysta. Moje osobiste standardy kodu mogą być również frustrujące, ale zawsze mam wrażenie, że robię przysługę światu / firmie / zespołowi, wdrażając je. Więc nie sądzę, że próbujesz zrobić zbyt wiele - wyniki będą się różnić w zależności od miejsca, ale przynajmniej starasz się.

Wydaje się, że to duży przykład dawania przykładu .

Istnieją dwa nieodłączne aspekty ludzkiej natury, z którymi walczysz:

• Kreatywni ludzie nie lubią procesów.
• Większość ludzi nie lubi zewnętrznych negatywnych ocen ich jakości.

Bardzo trudno jest z tym walczyć za pomocą wykładów, deklaracji zarządczych, a nawet logiki. Musisz wygrać, wykorzystując alternatywny aspekt ludzkiej natury.

• Ludzie naśladują zachowanie najlepszych pracowników

Jeśli najlepsi pracownicy użyją TDD i zadziała, proces się rozszerzy. Jeśli nie, to nie będzie. Jeśli chcesz kogoś przekonać, to 1 lub 2 najlepszych pracowników.

Poprosić ich.

Mówisz, że ludziom powiedziano, i zgadzasz się, że powinni napisać więcej testów. Dlaczego nie są?

To nie może (często nie jest) kwestia prostej motywacji. Mogą o nich zapomnieć. Mogą odczuwać presję czasu. Mogą nie wiedzieć, jak pisać dobre testy. Mogą myśleć, że jesteś tak dobry, że nie muszą tego robić. Znajomość pierwotnej przyczyny pomoże lepiej rozwiązać problem.

Można by pomyśleć, że testy jednostkowe byłyby samą sprzedażą. Nie wiem, jak działa Twoja firma, ale gdy pojawia się problem podczas wdrażania produkcji, pracujemy nad nim, dopóki nie zostanie naprawiony. Nie ma znaczenia, czy stanie się to o 2 nad ranem w niedzielę rano. Jest to dla nas bardzo rzadkie, ale kiedy to robi, jest do bani.

Zacznę od pytania, ile razy musieli wstawać w środku nocy, aby naprawić jakiś poważny problem, który można łatwo znaleźć zautomatyzowanym testowaniem. Nie oznacza to, że automatyczne testowanie naprawi wszystko, ale powinno to pomóc w zmniejszeniu tego.

Drugim dużym sprzedawcą jest cykl kontroli jakości. Przed rozpoczęciem TDD w mojej firmie publikowaliśmy nowe wersje QA, aby testować co tydzień. Stworzyliby stos błędów z tego wydania, naprawiliśmy te błędy i wypchnęliśmy kolejne wydanie. Powtarzaj aż do zakończenia. Pierwszy projekt TDD nie wymagał wypchnięcia do kontroli jakości dopiero po kilku tygodniach. Liczba znalezionych błędów była bardzo, bardzo mała. 10% w porównaniu do podobnego projektu. Czy w ogóle masz te zestawienia dla swojego zespołu?

Innym ważnym punktem sprzedaży było to, jak wyglądał kod po objęciu TDD, był łatwiejszy do odczytania, ponieważ chcieliśmy ułatwić testowanie. Pokaż porównanie między kodem napisanym dla testów jednostkowych a kodem niepisanym.

Na koniec pokaż im, w jaki sposób będą mogli z ufnością refaktoryzować kod.

Miej to na uwadze, gdy nie masz ochoty pisać testów. :)

Chciałbym rozwinąć odpowiedź HLGEM , szczególnie ten rozdział:

Kolejnym powodem jest to, że przy dużej istniejącej, nieprzetestowanej bazie kodu pisanie testów wydaje się być przytłaczające - niekończąca się praca (jak pranie i mniej więcej tak ekscytujące). Więc ludzka natura uważa, że ​​to zbyt wiele, aby stawić temu czoła, więc pominę to.

Odkryłem, że kod, który piszę z zamiarem pisania testów, jest znacznie lepszy niż kod, który piszę bez zamiaru pisania testów; zadaję sobie pytanie Jak przetestować tę funkcję? wymusza lepsze zaprojektowanie każdej funkcji. (Mniej polegania na danych globalnych lub półglobalnych; IO oddzielone od obliczeń; funkcje wykonują tylko jedną rzecz; spójna obsługa błędów; i tak dalej.)

Próba przetestowania starego kodu, który nie został napisany z myślą o testowaniu, może być bardziej frustrująca.

Użyłem kilku technik:

a) skonfigurować automatyczną kompilację. Gdy ktoś psuje coś, co przetestowałeś, pokaż mu, jak wykrył go test i jak bardzo byłby to błąd.

b) Wykonuj złożone projekty za pomocą testów (jeździsz). To pokaże, jak mało jest błędów w tym projekcie. Miałem jeden złożony projekt interakcji z serwerem, który zaczął działać bezbłędnie. Nigdy nie zawiodła kontroli jakości, a wszystkie testy integracyjne przebiegły w 100% sprawnie. System ten stał się znany jako wysoce stabilny i ogólne zarządzanie było z niego zadowolone. To, co robisz w tych sytuacjach, pokazuje, w jaki sposób testy jednostkowe to umożliwiły.

c) Przyciągaj jedną osobę na raz. Ten, który cię słucha. Weź na siebie błędy i pokaż, jak testy ujawniają głębokie i trudne problemy. To pomaga. To nigdy nie jest łatwe. Ale kiedy zdobędziesz fana, on tylko pomoże. To efekt domina.

Piec testowanie jednostkowe w tym procesie. Jeśli w produkcji pojawia się błąd, który jest zbyt oczywisty, aby go złapać w teście jednostkowym, ten facet ponosi winę. Przydziel ludziom, aby napisali każdy test, który przeprowadzają. Losowo wybieraj sprawy i obserwuj wykonanie kilku spraw co tydzień. Wykonując testy jednostkowe, ludzie będą pytać o wymagania i ostatecznie powiązać je z rozwojem oraz, mam nadzieję, opracować oprogramowanie, które zarówno wymagało, jak i działa :)