Kolega niechętny do korzystania z testów jednostkowych „ponieważ chodzi o kodowanie”

Kolega nie chce używać testów jednostkowych i zamiast tego wybiera szybki test, przekazuje go użytkownikom, a jeśli wszystko jest w porządku, jest publikowany na żywo. Nie trzeba dodawać, że niektóre błędy się przedostają.

Wspomniałem, że powinniśmy pomyśleć o stosowaniu testów jednostkowych - ale ona była temu przeciwna, kiedy zdano sobie sprawę, że trzeba napisać więcej kodu. To sprawia, że ​​jestem w stanie coś zmodyfikować i nie jestem pewien, czy dane wyjściowe są takie same, zwłaszcza, że ​​jej kod to spaghetti i staram się go refaktoryzować, kiedy mam szansę.

Więc jaki jest dla mnie najlepszy sposób?

Nie zdaje sobie sprawy z zalet testowania jednostkowego i właśnie to musisz zmienić:

• Jej świadomość.

Będziesz musiał ją udowodnić, że poprawi to jej pracę nie tylko twoją. Będzie to trudne, prawdopodobnie spróbuje skoncentrować się na każdym negatywnym aspekcie, jaki może znaleźć, jeśli boi się zmian.

Możesz spróbować porozmawiać z nią na temat wszystkich korzyści i wysłuchać wszystkich jej kontrargumentów. Poczekaj, aż skończy mówić, zanim zaczniesz mówić.

Aby się przygotować, powinieneś poszukać na P.SE lub Google wszystkich spraw związanych z zarządzaniem lub programistami, którzy martwią się testami jednostkowymi i zebrać odpowiedzi, których użyjesz podczas dyskusji z kolegą.

Wystarczy jej wysłuchać i przedstawić dowód, że poprawi to jej pracę, bardzo ci pomoże. Udowadniasz, że martwi Cię jej opinia, i przekazujesz jej wszystkie dane, których potrzebuje, aby przeanalizować sytuację i ostatecznie zmienić zdanie.

Napisz test jednostkowy (nie mów jej)

Poczekaj, aż coś się zepsuje, Pozwól jej wykonać testy ręczne przez dwa dni, a następnie przeprowadź testy jednostkowe i znajdź błąd w ciągu trzech sekund.

Kryć się...

Automatyzacja ręcznych zadań w innym przypadku powinna spodobać się każdemu programistowi.

Więc nie „pisze więcej kodu”, robi mniej ręcznie.

(Jednym z) punktów zautomatyzowanych testów jest powtarzalność . Jeśli zrobić szybki test ręcznie, to może zrobić to szybciej niż pisanie samo jak badanej jednostki (dla początkujących testów jednostkowych przynajmniej - ktoś doświadczył w testach jednostkowych może wypuszczają testy dość szybko).

Ale co, gdy jutro lub w przyszłym tygodniu wprowadzona zostanie niewielka (lub duża ...) zmiana w kodzie? Czy twój kolega chętnie powtarzałby te same testy ręczne po każdej zmianie, aby upewnić się, że nic nie jest zepsute? A może wolałaby „kodować i modlić się”?

Im bardziej kod jest zmieniany, tym bardziej testy jednostkowe zwracają początkową inwestycję . Nie trzeba długo czekać na pozytywne strony, nawet bez testów wykrywających błędy. Ale regularnie to robią - w tym momencie stają się bezcenne. A gdy ktoś doświadczy poczucia bezpieczeństwa i zaufania do kodu, który daje udany test jednostkowy, zwykle nie ma odwrotu.

Jeśli jest w pewnym stopniu przekonana, ale boi się zapuścić w nowy obszar, zaoferuj jej sesję programowania par, aby wspólnie napisać swoje pierwsze testy jednostkowe . Wybierz klasę, która nie jest zbyt trudna do przetestowania, ale na tyle złożona, że ​​warto ją przetestować.

Jeśli jednak nie jest przekonana, być może będziesz musiał zebrać twarde fakty . Takie mogą być fakty

• wskaźniki wad w kodzie napisanym przez ciebie w porównaniu do jej
• pisząc zestaw testów jednostkowych względem jej kodu i dokumentując znalezione błędy.

Zbierz trochę takich danych, a następnie uprzejmie pokaż jej wyniki. Jeśli to wciąż nie wystarczy, aby ją przekonać, być może będziesz musiał omówić problem i udostępnić zebrane dowody kierownictwu. To powinna być tylko ostatnia deska ratunku, ale czasem nie ma innego wyjścia.

Napisz podstawową wersję testu dla najgorszych fragmentów jej kodu, zmodyfikuj go na podstawie tych testów, a następnie zadeklaruj zarządowi, że testowanie jednostkowe na ciągłych kompilacjach poprawi wydajność. Zmiany przychodzą łatwiej, gdy wymaga tego pracodawca, niż ewangelizuje je pojedynczy programista.

Nie wiem, jak to odpowiednio wyrazić, ale: jeśli refaktoryzujesz jej kod „kiedy masz szansę” ... cóż, prawdopodobnie myśli, że jesteś trochę podstępny za zaangażowanie się w „jej biznes” , więc rzadziej słucha cię z otwartym umysłem. Z mojego doświadczenia wynika, że ​​ludzie przywiązują się do tego, co zrobili - nawet jeśli nie jest to strasznie dobre.

Aby zagrać w adwokata diabłów: ma rację. Zwykle określam to jako:

Automatyczne testy rozwiązują problemy związane z nadmiarem kodu przy jeszcze większej liczbie kodów.

Racjonalne uzasadnienie:

• badanie dotyczące korelacji wskaźnika błędów i wskaźników OO , nagłówek: „Po kontrolowaniu wielkości [klasy] żadna z badanych przez nas wskaźników nie była już związana z podatnością na błędy” . (Badanie omawia wielkość klasy. Czy ten efekt rozciąga się na rozmiar podstawy kodu? Prawdopodobnie. Moim zdaniem )
• Empirycznie duże projekty idą powoli do przodu. „5 000 linii w ciągu jednego dnia w nowym projekcie” vs. „10 linii dziennie w dużym”. Czy to oznacza, że ​​„opór” wobec zmiany rośnie wraz z rozmiarem podstawy kodu?
• Zawsze ogłaszamy, że „nie ma najlepszego języka, zależy to od problemu”. Jednym z kluczowych wymagań jest łatwe modelowanie encji problemowych i operacji w wybranym języku. Czy to nie sugeruje, że wybór języka, w którym wyrażanie problemu jest bardziej skomplikowane, jest gorszy i czy to nie koreluje z ostatecznym rozmiarem podstawy kodu?

Teraz jest kilka argumentów przeciwko temu z łatwością. Pozwólcie mi zająć się tymi, o których mogę myśleć:

• rozmiar a prostota: Oczywiście możliwe jest, aby kod był krótszy i gorszy. Jest to jednak problem tylko przy porównywaniu baz kodu o różnych stosunkach zwięzłości do prostoty, w dyskusji można założyć, że możemy w jakiś sposób kontrolować ten czynnik.

• Testy jednostkowe wywierają presję na zmniejszenie zależności i empirycznie zgadzam się, że zmniejszenie zależności może złagodzić problemy z rozmiarem kodu (w tym sensie, że w przypadku dwóch baz kodu o podobnej wielkości, ta z większą liczbą współzależności jest gorsza). Jednak zmniejszając zależności między jednostkami kodu produkcji, wprowadza sprzężenie między testem a samą jednostką.

TL; DR: Nie twierdzę, że testy jednostkowe są złe; Pytam: czy istnieje punkt progowy, w którym boli testy, co jest skorelowane z ilością kodu?

Myślę, że jesteś w trudnej sytuacji. Byłem w zespole, w którym ludzie nie pisali testów jednostkowych lub, co gorsza, okropnych, niemożliwych do utrzymania testów jednostkowych. Ale wszyscy byli świadomi, że testy jednostkowe są dobre.

Zatem uzyskanie dobrej jakości zestawu testów jednostkowych zespołu było długą i trudną drogą. Zawsze zwracaj uwagę na to, gdzie można poprawić, komunikować pomysły, dzielić się doświadczeniami.

Z drugiej strony masz programistę, który nawet nie zauważył korzyści. A następnie kody spaghetti. Myślę, że jednym z najważniejszych powodów w tym konkretnym przypadku jest fakt, że pisanie dobrych testów jednostkowych wymusza luźno sprzężoną konstrukcję. Więc zachęcenie jej do napisania testu może na dłuższą metę poprawić również „prawdziwy” kod.

Ale myślę, że ostatecznie jest to decyzja zespołu (nie wiem, ilu jesteś w zespole?). Jeśli zespół może dojść do porozumienia, że ​​powinien istnieć dobrze zakrojony pakiet testów jednostkowych, wszyscy muszą się dostosować, dzielić doświadczeniami i pozwolić zespołowi rosnąć razem.

Jeśli jednak zespół nie może dojść do porozumienia, że ​​powinieneś pisać testy jednostkowe, sugeruję, abyś znalazł inny zespół programistów do pracy;)

Czy ona jest szefem?

Jeśli tak, to utknąłeś, chyba że możesz ją przekonać o korzyściach, które są zasadniczo zgodne z zasadą „uncja zapobiegania jest warta funta lekarstwa”. Błędy przechodzą. TDD pomaga to złagodzić, budując spójne wyniki.

Czy ona nie jest szefem?

Jakie są standardy kodowania, w których pracujesz? Dlaczego wolno jej wyrzucać kod spaghetti? Przedstaw szefowi uzasadnienie biznesowe: „Spędzimy dużo mniej czasu na błędach, jeśli spędzimy trochę więcej czasu na TDD”. Przekonaj kogoś, kto może wymusić zmianę w uzasadnieniu biznesowym.

Dokumentuj przypadki, w których TDD mógł zaoszczędzić czas i $$ MONEY $$.

Ten błąd się pojawił. Zostałby złapany przed uruchomieniem. Wydanie 2 godzin profilaktyki pozwoliłoby nam zaoszczędzić 10 godzin leczenia. Stało się to tu i tu i tutaj. 10 godzin pracy, które pozwoliłyby firmie zaoszczędzić 30 roboczogodzin. To tyle pieniędzy.

To pozwala mi coś modyfikować

Czemu?

Stworzyli problem. Powinni to rozwiązać.

Który menedżer na to pozwala? Dlaczego kod buggy innej osoby jest teraz twoim problemem?

Masz kolegę i menedżera, którzy sprawiają, że tak się dzieje. A sprzątając ich bałagan, jesteś chętnym i aktywnym uczestnikiem.

Nic się nie zmieni, jeśli nie odczują bólu złej jakości.

Ma rację, testy jednostkowe to „więcej kodu”.

Jednak po prostu trzeba napisać więcej kodu, aby upewnić się, że program działa tak, jak powinien (w kółko). To nie jest zmarnowany czas. Jest to tak samo część systemu, jak jego podstawowe elementy.

Rzuć jej wyzwanie:

1. Co się stanie, jeśli ktoś, kto nie zna kodu, coś zmieni.
2. Co się stanie, jeśli ktoś niedoświadczony coś zmieni.
3. Koszt utrzymania systemu nie jest mierzony w czasie tworzenia. To propozycja długoterminowa. Pomyśl o całkowitym koszcie posiadania.
4. Jej oszacowanie (jeśli było to wymagane przed rozpoczęciem kodowania) powinno zawierać wymóg napisania testów jednostkowych. Ludzie biznesu nie tworzą wymagań, które bezpośrednio wymagają testów jednostkowych, ale implikują wymóg jakości i wymagają, aby przyszłe zmiany nie były pełne błędów lub aby ten sam programista zmienił źródło.

Mówiąc jako taki, który obecnie tworzy kod produkcyjny, a następnie testy jednostkowe zamiast TDD, co nie wydaje się być dobrym rozwiązaniem w moim obecnym miejscu (robiłem TDD w niektórych projektach, ale widzę to jako kolejne narzędzie w stara torba, a nie srebrna kula) ...

Może to być trudna sprzedaż. Nadal nie byłem w stanie sprzedać moich współpracowników podczas testów jednostkowych. Wiem, że zwykle popełniam o wiele więcej błędów w kodzie testów jednostkowych niż w kodzie produkcyjnym. Trochę frustrujące jest spędzanie tak dużo czasu na naprawianiu kodu testu jednostkowego ... Jednak przy modyfikowaniu kodu fajne jest ubezpieczenie. Świetny sposób na automatyczne testowanie warunków krawędziowych.

Pokaż jej, ile pomagają testy jednostkowe, samodzielnie tworząc testy jednostkowe.

Jak powiedział kiedyś św. Franciszek: „Głoście zawsze. W razie potrzeby używaj słów”.

Jeśli zauważy, że Twój kod używa testów jednostkowych i że możesz szybciej rozwiązywać błędy za pomocą testów jednostkowych, może to zmienić jej zdanie. Ale może nie.

Bez względu na wynik, nie uważa, że ​​naciskasz na nią coś, czego nie chcesz zrobić. To musisz zmienić, przekonanie, że nie dajesz przykładu.