Jak zmusić młodszych programistów do pisania testów? [zamknięte]

Wykonaj przegląd kodu przed każdym commitem (nawet jeśli jest to 1 minuta "zmieniłem nazwę zmiennej"), a w ramach przeglądu kodu przejrzyj wszelkie testy jednostkowe.

Nie podpisuj commita, dopóki testy nie zostaną wdrożone.

(Również-jeśli jego praca nie była testowana-dlaczego w ogóle była produkowana? Jeśli nie jest testowany, nie wpuszczaj go, wtedy nie będziesz musiał pracować w weekendy)

Dla siebie, zacząłem nalegać, aby każdy błąd, który znajdę i poprawię, był wyrażony jako test:

"Hmmm, to nie w porządku..."
1. Znajdź możliwy problem
2. Napisz test, pokaż, że Kod się nie powiedzie
3. Napraw problem
4. pokaż, że nowy kod przechodzi
5. Loop if the original problem persists

Staram się to robić nawet podczas wbijania rzeczy, i robię to mniej więcej w tym samym czasie, tylko z częściowym zestawem testów już w miejsce.

(nie mieszkam w komercyjnym środowisku programistycznym i często jestem jedynym programistą pracującym nad danym projektem.)

Wyobraź sobie, że jestem fałszywym programistą, o imieniu... Marco. Wyobraź sobie, że ukończyłem szkołę nie tak dawno temu i nigdy nie musiałem pisać testów. Wyobraź sobie, że pracuję w firmie, która tak naprawdę nie egzekwuje i nie prosi o to. OK? dobrze! Teraz wyobraź sobie, że firma przechodzi na testy i próbują mnie z tym połączyć. Podam nieco złośliwą reakcję na wspomniane do tej pory przedmioty, tak jakbym nie robił na ten temat żadnych badań.

Zacznijmy od twórca:

Pokazanie, że projekt staje się prostszy.

Jak napisać więcej, uprościć sprawę? Teraz musiałbym mieć na oku coraz więcej przypadków itp. To komplikuje sprawę. Podaj mi solidne szczegóły.

Pokazanie go zapobiega wadom.

Wiem o tym. Dlatego nazywa się je testami. Mój kod jest dobry i sprawdziłem go pod kątem problemów, więc nie widzę, gdzie te testy by pomogły.

Making it an ego mówi, że tylko źli Programiści tego nie robią.

Ohh, więc uważasz, że jestem złym programistą tylko dlatego, że nie robię tak dużo używanych testów. Jestem na Ciebie obrażony i pozytywnie wkurzony. Wolę mieć pomoc i wsparcie niż słowa.

@Justin Standard : na początku nowego propect sparuj Juniora z sobą lub innym starszym programistą.

Ohh, to jest tak ważne, że środki zostaną wydane upewniając się, że widzę, jak się sprawy mają zrobione, i niech mi ktoś pomoże, Jak to się robi. To jest pomocne, i może zacznę robić to częściej.

@Justin Standard: Read Unit Testing 101 prezentacja Kate Rhodes.

Ahh, to była ciekawa prezentacja i skłoniła mnie do zastanowienia się nad testowaniem. Poruszyło to pewne kwestie, które powinienem wziąć pod uwagę i mogło nieco wpłynąć na moje poglądy.

Chciałbym zobaczyć bardziej atrakcyjne artykuły i inne narzędzia, które pomogą mi w pogodzenie się z myśleniem, że to właściwy sposób na robienie rzeczy.

@Dominic Cooney : poświęć trochę czasu i podziel się technikami testowania.

Ahh, to pomaga mi zrozumieć, czego się ode mnie oczekuje, jeśli chodzi o techniki, i umieszcza więcej przedmiotów w moim worku wiedzy, które mógłbym użyć ponownie.

@Dominic Cooney : odpowiadaj na pytania, przykłady i książki.

Posiadanie osoby (osób) do odpowiedzi na pytanie jest pomocne, może daj mi szansę spróbować. Dobre przykłady są świetne, a to daje mi coś do celowania i coś do szukania odniesienia. Książki, które są związane z tym bezpośrednio są doskonałym odniesieniem.

@Adam Hayle : Recenzja Z Niespodzianką.

Powiedz co, wyrosłeś na coś, na co jestem kompletnie nieprzygotowany. Czuję się z tym nieswojo, ale zrobię co w mojej mocy. Będę teraz przerażona i lekko przerażona, że to się znowu pojawi, dziękuję. Jednak taktyka straszenia może i zadziałało, ale ma swoje koszty. Jeśli jednak nic innego nie zadziała, może to być po prostu potrzebne pchnięcie.

@Rytmis : przedmioty są uważane za wykonane tylko wtedy, gdy mają przypadki testowe.

Ohh, ciekawe. Widzę, że naprawdę muszę to zrobić teraz, inaczej niczego Nie dokończę. To ma sens.

@jmorris : pozbądź się / Poświęć.

blaski, blaski, blaski - jest szansa, że się nauczę, a dzięki wsparciu i pomocy mogę stać się bardzo ważną i funkcjonalną częścią zespołów. To jedna z moich wad, ale nie na długo. Jeśli jednak tego nie dostanę, rozumiem, że pójdę. Myślę, że ją zdobędę.

W końcu wsparcie mojego zespołu odgrywa dużą rolę w tym wszystkim. Posiadanie osoby poświęcającej swój czas na pomoc i wprowadzenie mnie w dobre nawyki jest zawsze mile widziane. Następnie, po dobrej sieci wsparcia byłoby świetnie. Byłoby zawsze doceniamy, że ktoś przychodzi kilka razy później i przechodzi przez jakiś kod, aby zobaczyć, jak wszystko płynie, nie w recenzji per se, ale bardziej jako przyjazna wizyta.

Rozumowanie, przygotowywanie, Nauczanie, monitorowanie, wsparcie.

Zauważyłem, że wielu programistów widzi wartość testów na racjonalnym poziomie. Jeśli słyszałeś takie rzeczy jak "tak, Wiem, że powinienem to przetestować, ale naprawdę muszę to zrobić szybko" to wiesz, co mam na myśli. Jednak na poziomie emocjonalnym czują, że coś robią tylko wtedy, gdy piszą prawdziwy kod.

Celem powinno być więc, aby w jakiś sposób zrozumieli, że testowanie jest w rzeczywistości Tylko sposobem mierzenia, kiedy coś jest "zrobione", a tym samym daj im wewnętrzną motywację do pisania testów.

Obawiam się, że to o wiele trudniejsze niż powinno być. Usłyszysz wiele wymówek w stylu "bardzo się spieszę, napiszę to później, a potem dodam testy" - i oczywiście kontynuacja nigdy się nie wydarzy, ponieważ, o dziwo, są oni tak samo zajęci w przyszłym tygodniu.

Oto co bym zrobił:

• Pierwszy raz... "zrobimy ten projekt wspólnie. Ja napiszę testy, a Ty napiszesz kod. Zwróć uwagę na to, jak piszę testy, bo w ten sposób robimy rzeczy tutaj i tego się po tobie spodziewam."

• Po tym... "Skończyłeś? Świetnie! Najpierw przyjrzyjmy się testom, które napędzają Twój rozwój. Żadnych testów? Daj mi znać, kiedy to się skończy, a my przełożymy szukanie na Twój kod. Jeśli potrzebujesz pomocy w sformułowaniu testów, daj mi znać, a ja ci pomogę."

Jako młodszy programista, wciąż staram się nabrać nawyku pisania testów. Oczywiście nie jest łatwo wychwycić nowe nawyki, ale myśląc o tym, co sprawi, że to zadziała dla mnie, muszę +1 komentarzy na temat recenzji kodu i coachingu / programowania par.

Warto również podkreślić długoterminowy cel testowania: zapewnienie, że to, co działało wczoraj, działa nadal dzisiaj, a w przyszłym tygodniu i w przyszłym miesiącu. Mówię tak tylko dlatego, że w odpowiedziach nie widziałem, że wspominany.

Robiąc recenzje kodu (jeśli się na to zdecydujesz), upewnij się, że twój młody dev wie, że nie chodzi o uśpienie go, tylko o ulepszenie kodu.Ponieważ w ten sposób jego pewność siebie jest mniej podatna na uszkodzenia. I to jest ważne. Z drugiej strony, tak samo jak wiedza, jak mało wiesz.

Oczywiście, tak naprawdę nic nie wiem. Ale mam nadzieję, że słowa były użyteczne.

Edit: [ Justin Standard]

Don ' t put to, co masz do powiedzenia, jest słuszne.

Jeśli chodzi o recenzje kodu: przekonasz się, że nie tylko junior dev nauczy się w tym procesie, ale także recenzenci. Wszyscy uczestnicy przeglądu kodu dowiadują się, czy uczynisz z niego proces współpracy.

Szczerze mówiąc, jeśli musisz włożyć to wiele wysiłku, aby nakłonić go do zrobienia czegoś, być może będziesz musiał pogodzić się z myślą, że może po prostu nie pasować do drużyny i być może będziesz musiał odejść. To nie musi oznaczać zwolnienia go... może to oznaczać znalezienie innego miejsca w firmie, w którym jego umiejętności są bardziej odpowiednie. Ale jeśli nie ma innego miejsca...wiesz, co robić.

Zakładam, że jest też dość nowym pracownikiem (

Jeśli tak jest, jedną z rzeczy, które znalazłem działa jest mieć coś w rodzaju " niespodzianka nowy wynajem przeglądu."Nie ma znaczenia, czy nigdy wcześniej tego nie robiłeś...nie będzie wiedział. Posadź go i powiedz, że przejdziesz przez jego występ i pokażesz mu prawdziwe liczby...weź swój normalny arkusz recenzji (masz formalną recenzję proces w porządku?) I zmienić nagłówek, jeśli chcesz, aby wyglądało to oficjalnie i pokazać mu, gdzie stoi. Jeśli pokażesz mu w bardzo formalnym otoczeniu, że nie robienie testów negatywnie wpływa na jego ocenę wydajności, a nie tylko "Dręczenie" go o to, miejmy nadzieję, że dostanie punkt. Musisz mu pokazać, że jego działania będą miały na niego wpływ.

Wiem, lepiej trzymaj się od tego z daleka, bo to nie jest oficjalne... ale myślę, że jesteś wewnątrz powód, żeby to zrobić i prawdopodobnie będzie to dużo tańsze niż zwalnianie go i zatrudnianie kogoś nowego.

On już to robi. Naprawdę. Po prostu tego nie zapisuje. Nie jesteś przekonany? Zobacz jak przechodzi przez standardowy cykl rozwoju:

• Napisz kawałek kodu
• Compile it
• Run to see what it does
• Napisz następny fragment kodu

Krok # 3 jest testem. Już robi testy, robi to ręcznie. Zadaj mu to pytanie: "Skąd wiesz, że jutro kod z dzisiaj nadal działa? Odpowie: "to taka mała ilość kod!"

Zapytaj: "może w przyszłym tygodniu?"

Gdy nie ma odpowiedzi, zapytaj: "jak chcesz, aby twój program powiedział ci, gdy zmiana zepsuje coś, co działało wczoraj?"

Na tym polega automatyczne Testowanie jednostek.

Jako młodszy programista myślałem, że Id ujawnia, jak to jest, gdy znalazłem się w podobnej sytuacji do twojego młodszego programisty.

Kiedy po raz pierwszy wyszedłem z uni, odkryłem, że nie wyposażono mnie do radzenia sobie z prawdziwym światem. Tak, znałem trochę podstaw Javy i trochę filozofii (nie pytaj), ale o to chodziło. Kiedy po raz pierwszy dostałem pracę, było to trochę zniechęcające. Powiem ci, że byłem prawdopodobnie jednym z największych kowbojów w okolicy. razem trochę poprawki błędów / algorytm bez komentarzy / testowanie / dokumentacja i wysłać go za drzwi.

Miałem szczęście być pod nadzorem pewnego rodzaju ibardzo cierpliwego starszego programisty. Na szczęście dla mnie, postanowił usiąść ze mną i spędzić 1-2 tygodnie przeglądając mój bardzo zhakowany kod togethor. Tłumaczył, gdzie popełniłem błąd, drobniejsze punkty c i pointers (boy zrobił to mnie zdezorientować!). Udało nam się napisać całkiem przyzwoitą klasę / moduł w około tydzień. Mogę tylko powiedzieć, że gdyby starszy dev nie zainwestował czasu, aby pomóc mi na właściwej drodze, prawdopodobnie nie wytrzymałbym zbyt długo.

Szczęśliwie, 2 lata w dół linii, mam nadzieję, że niektórzy z moich kolegów może nawet uznać mnie przeciętnym programistą.

Take home points

1. większość uniwersytetów jest bardzo zła w przygotowywaniu studentów do prawdziwego świata
2. sparowane programowanie naprawdę mi pomogło. To nie znaczy, że to pomoże wszystkim, ale to dla mnie zadziałało.

Przypisz je do projektów, które nie wymagają "najwyższej jakości stabilnego kodu", jeśli to twoja sprawa i pozwól programiście jr. zawieść. Niech to oni "przyjdą w weekend" naprawić swoje błędy. Zjedz dużo obiadu i porozmawiaj o praktykach tworzenia oprogramowania (nie wykładach, ale dyskusjach). Z czasem zdobędą i opracują najlepsze praktyki w zakresie wykonywania powierzonych im zadań.

Kto wie, mogą nawet wymyślić coś lepszego niż techniki Twojego zespołu obecnie zastosowania.

Jeśli młodszy programista, lub ktokolwiek inny, nie widzi wartości w testing, wtedy trudno będzie im to zrobić...kropka.

Sprawiłbym, że młodszy programista poświęciłby swój weekend, aby naprawić błąd. Jego działania (lub ich brak) nie wpływają bezpośrednio na niego. Ponadto, niech będzie jasne, że nie będzie widział awansu i / lub podwyżek płac, jeśli nie poprawi swoich umiejętności w testowaniu.

W końcu, nawet z całą twoją pomocą, zachętą, mentoringiem, może nie być pasuje do Twojej drużyny, więc puść go i poszukaj kogoś, kto to rozumie.

Popieram komentarz Rodeoclowna o sprawdzaniu kodu przy każdym commicie. Gdy zrobi to uczciwie kilka razy, nabierze nawyku testowania rzeczy.

Nie wiem, czy trzeba blokować takie commity. W moim miejscu pracy każdy ma darmowy commit do wszystkiego, a wszystkie komunikaty SVN commit (z diffami)są wysyłane do zespołu.

Uwaga: ty naprawdę chceszthunderbird colored-diffs addon jeśli planujesz to zrobić.

My boss or myself (the 2 'starszych' programistów) skończy się czytaniem commitów, a jeśli są jakieś rzeczy typu "zapomniałeś dodać testy jednostkowe", po prostu przerzucamy maila lub idziemy porozmawiać z tą osobą, wyjaśniając, dlaczego potrzebowali testów jednostkowych czy czegokolwiek innego. Wszyscy inni są zachęcani do przeczytania commitów, ponieważ jest to świetny sposób, aby zobaczyć, co się dzieje, ale młodsi deweloperzy nie komentują zbyt wiele.

Możesz pomóc zachęcić ludzi do przyzwyczajenia się do tego, powtarzając okresowo rzeczy w stylu "Hej, bob, czy widziałeś, że commit zrobiłem dziś rano, znalazłem fajną sztuczkę, gdzie można zrobić bla bla cokolwiek, przeczytać commit i zobaczyć, jak to działa!"

NB: mamy 2 "starszych" programistów i 3 młodszych. Może to nie być skalowane lub konieczne może być dostosowanie procesu nieco z większą liczbą programistów.

1. Uczyń pokrycie kodu częścią recenzji.
2. Uczyń" napisz test, który ujawnia błąd " warunkiem koniecznym do naprawienia błędu.
3. Wymagaj pewnego poziomu pokrycia, zanim kod będzie mógł zostać sprawdzony.
4. Znajdź dobrą książkę na temat Test-driven development i użyj jej, aby pokazać, jak test-first może przyspieszyć rozwój.

Dużo psychologii i pomocnych technik "mentoringu", ale szczerze mówiąc, sprowadza się to tylko do " pisania testów, jeśli chcesz mieć pracę, jutro."

Możesz to zrobić w dowolnych terminach, które uważasz za właściwe, ostre lub miękkie, to nie ma znaczenia. Ale faktem jest, że programiści nie są płaceni za to, aby po prostu wrzucić kod i sprawdzić go-płacą im, aby starannie ułożyć kod, następnie złożyć testy, następnie przetestować swój kod, a następnie sprawdzić całość. (Przynajmniej tak to brzmi, z twojego opisu.)

Dlatego, jeśli ktoś ma zamiar odmówić wykonywania swojej pracy, wyjaśnij mu, że może zostać w domu, jutro, a Ty zatrudnisz kogoś, kto będzie wykonywać tę pracę.

Powodzenia.

Zmień na chwilę jego opis pracy, aby wyłącznie pisać testy i utrzymywać testy. Słyszałem, że wiele firm robi to dla świeżo nowych niedoświadczonych ludzi przez jakiś czas, gdy zaczynają.

DODATKOWO, wystawić wyzwanie, gdy jest w tej roli: napisz testy, które a) zawiodą na bieżącym kodzie a) spełnią wymagania oprogramowania. Mam nadzieję, że to spowoduje, że stworzy solidne i dokładne testy (ulepszenie projektu) i sprawi, że będzie lepszy w pisaniu testów na kiedy ponownie integruje się z core development.

Edit>

Jeśli twój kolega nie ma doświadczenia w pisaniu testów, może ma trudności z testowaniem poza prostymi sytuacjami, a to przejawia się jako nieodpowiednie testowanie. Oto co bym spróbował:

• poświęć trochę czasu i podziel się z kolegą technikami testowania, takimi jak iniekcja zależności, szukanie przypadków skrajnych itp.
• Oferta odpowiedzi na pytania dotyczące testów.
• Wykonaj przez jakiś czas przegląd kodu testów. Poproś kolegę o zapoznanie się z Twoimi zmianami które są przykładem dobrych testów. Spójrz na ich komentarze, aby sprawdzić, czy naprawdę czytają i rozumieją Twój kod testowy.
• Jeśli są książki, które pasują szczególnie dobrze do filozofii testowania Twojego zespołu, daj mu kopię. Może to pomóc, jeśli Twoje opinie lub dyskusje dotyczące recenzji kodu odnoszą się do książki, więc on lub ona ma wątek do podjęcia i śledzenia.

Nie chciałbym szczególnie podkreślać czynnika wstydu/winy. Warto zaznaczyć, że testowanie jest szeroko przyjęte, dobra praktyka i to, że pisanie i utrzymywanie dobrych testów to profesjonalna uprzejmość, więc koledzy z drużyny nie muszą spędzać weekendów w pracy, ale ja bym tych punktów nie belaborował.

Jeśli naprawdę potrzebujesz "być twardym", wprowadź bezstronny system; nikt nie lubi czuć się wyróżniony. Na przykład twój zespół może wymagać kodu, aby utrzymać pewien poziom zasięgu testu( który może być gamed, ale przynajmniej może być zautomatyzowany); wymaga nowego kodu testy; wymagaj od recenzentów, aby brali pod uwagę jakość testów podczas wykonywania recenzji kodu; i tak dalej. Wprowadzenie tego systemu powinno wynikać z konsensusu zespołu. Jeśli uważnie moderujesz dyskusję, możesz odkryć inne powody, dla których testy twojego kolegi nie są tym, czego oczekujesz.

Obowiązkiem jego mentora jest nauczenie go / jej. Jak dobrze uczysz go / ją, jak testować. Programujesz z nim w parze? Junior raczej nie wie jak ustawić dobry test na xyz.

Jako Junior freshout szkoły zna wiele pojęć. Jakaś technika. Trochę doświadczenia. Ale w końcu Junior jest potencjalny. Prawie każda funkcja, nad którą pracują, będzie coś nowego, czego nigdy wcześniej nie robili. Pewnie Junior mógł zrobić prosty wzorzec stanu dla projektu w klasie, otwieranie i zamykanie "drzwi", ale nigdy rzeczywiste zastosowanie wzorców.

On / Ona będzie tylko tak dobry, jak dobrze uczysz. Gdyby byli w stanie "po prostu to dostać", myślisz, że w pierwszej kolejności zajęliby juniorską pozycję?

Z mojego doświadczenia wynika, że Juniorzy są zatrudniani i mają prawie taką samą odpowiedzialność jak Seniorzy, ale po prostu płacą mniej, a potem ignorują, gdy zaczynają słabnąć. Wybacz, jeśli wydaję się zgorzkniały, to bo jestem.

@ jsmorris

Kiedyś miałem starszego dewelopera i "architekta" brzydzę się mną i testerem (to była moja pierwsza praca po studiach) w e-mail za to, że nie zostaję do późna i kończę tak" łatwe " zadanie przedwczoraj. Byliśmy na tym cały dzień i nazwaliśmy to kończy się o 7pm, byłem thrashing od 11am przed obiadem tego dnia i miał nękał każdego członka naszego zespołu o pomoc co najmniej dwa razy.

Odpowiedziałem i cc ' D zespół z: "Zawiodłem się na Tobie od miesiąca. I never get pomoc od zespołu. Będę w kawiarni po drugiej stronie ulicy, jeśli będziesz mnie potrzebował. Przykro mi, że nie mogłem debugować metody 12 parametr, 800 linii, że prawie wszystko jest zależne od."

Po ochłodzeniu się w kawiarni na godzinę, wróciłem do biura, wziąłem moje śmieci i wyszedłem. Po kilku dniach zadzwonili do mnie z pytaniem, czy przyjdę, powiedziałem, że przyjdę, ale miałem rozmowę kwalifikacyjną, może jutro.

" więc rezygnujesz?"

W repozytorium źródłowym: użyj hooków przed każdym zatwierdzeniem (na przykład przed zatwierdzeniem Hooka dla SVN)

W tym hooku sprawdź istnienie co najmniej jednego przypadku użycia dla każdej metody. Użyj Konwencji Organizacji testów jednostkowych, którą możesz łatwo wyegzekwować za pomocą haka przed zatwierdzeniem.

Na serwerze integracyjnym skompiluj wszystko i Regularnie sprawdzaj zasięg testu za pomocą narzędzia test coverage. Jeśli pokrycie testowe nie jest 100% dla kodu, Zablokuj wszelkie commity dewelopera. Powinien wyślij przypadek testowy, który obejmuje 100% kodu.

Tylko automatyczne kontrole mogą dobrze skalować projekt. Nie można wszystkiego sprawdzić ręcznie.

Programista powinien mieć środki, aby sprawdzić, czy jego przypadki testowe obejmują 100% kodu. W ten sposób, jeśli nie popełni w 100% przetestowanego kodu, jest to jego własna wina, a nie" oops, sorry I forgot".

Pamiętaj: ludzie nigdy nie robią tego, czego oczekujesz, zawsze robią to, co sprawdzasz.

Po pierwsze, jak wskazuje większość respondentów, jeśli facet nie widzi wartości w testach, niewiele możesz z tym zrobić, a już zwróciłeś uwagę, że nie możesz go zwolnić. Jednak porażka nie wchodzi w grę, więc co z kilkoma rzeczami, które możesz zrobić?

Jeśli Twoja organizacja jest wystarczająco duża, aby mieć ponad 6 programistów, zdecydowanie polecam posiadanie działu zapewnienia jakości (nawet jeśli jest to tylko jedna osoba, aby rozpocząć). Idealnie, powinieneś mieć stosunek 1 testera do 3-5 deweloperów. Chodzi o programistów ... są programistami, nie testerami. Muszę jeszcze przeprowadzić wywiad z programistą, który został formalnie nauczony właściwych technik QA.

Większość organizacji robi fatalną wadę przypisywania ról testowych do new-hire, osoby z najmniejszą ekspozycją na Twój kod - najlepiej, aby starsi Programiści zostali przeniesieni do roli QA, ponieważ mają doświadczenie w kodzie i (miejmy nadzieję) opracowali szósty zmysł dla zapachów kodu i punktów awarii, które mogą się pojawić.

Ponadto programista, który popełnił błąd, prawdopodobnie nie znajdzie defektu, ponieważ zwykle nie jest to błąd składni (który jest wykrywany podczas kompilacji), ale błąd logiczny - i ta sama logika działa podczas pisania testu, jak podczas pisania kodu. Nie każ osobie, która opracowała kod testować ten kod. znajdzie mniej błędów niż ktokolwiek inny.

W Twoim przypadku, jeśli możesz / align = "center" bgcolor = "# e0ffe0 " / cesarz chin / / align = center / Poproś go o przeczytanie "testowanie oprogramowania w realnym świecie: ulepszanie procesu", ponieważ oczywiście będzie potrzebował trochę szkolenia w swojej nowej roli. Jeśli mu się to nie spodoba, odejdzie, a twój problem nadal zostanie rozwiązany.

Nieco mniej mściwym podejściem byłoby pozwolić tej osobie robić to, w czym jest dobra (zakładam, że ta osoba została zatrudniona, ponieważ jest naprawdę kompetentna w programowaniu części pracy) i wynająć testera lub dwóch do wykonania testów (studenci często mają warunki praktyczne lub "kooperacyjne", pokochaliby ekspozycję i są tanimi) {]}

Uwaga na marginesie: w końcu będziesz chciał, aby zespół QA raportował do dyrektora QA, a przynajmniej nie do menedżera programistów, ponieważ posiadanie zespołu QA raport do menedżera, którego głównym celem jest uzyskanie produktu jest konflikt interesów.

Jeśli Twoja organizacja jest mniejsza niż 6, lub nie możesz uciec od tworzenia nowego team, polecam programowanie sparowane (PP). Nie jestem totalnym konwerterem wszystkich ekstremalnych technik programowania, ale zdecydowanie wierzę w programowanie sparowane. Jednak obaj członkowie zespołu programistycznego muszą być dedykowani, lub po prostu nie działa. Muszą przestrzegać dwóch zasad: inspektor musi w pełni zrozumieć, co jest kodowane na ekranie lub musi poprosić kodera, aby to wyjaśnił; koder może kodować tylko to , co może wyjaśnić-bez "zobaczysz" lub "zaufaj mi" lub machanie ręką będzie tolerowane.

Polecam PP tylko wtedy, gdy twoja drużyna jest do tego zdolna, ponieważ, podobnie jak testowanie, żadna ilość dopingu lub groźby nie przekona kilku pełnych ego introwertyków do współpracy, jeśli nie czują się z tym komfortowo. Uważam jednak, że między wyborem pisania szczegółowych specyfikacji funkcjonalnych a przeglądaniem kodu a programowaniem sparowanym, PP zwykle wygrywa.

Jeśli PP nie jest dla ciebie, to TDD jest twoją najlepszą szansą, ale tylko wtedy, gdy jej dosłownie. Test Driven Development oznacza, że najpierw piszesz testy, uruchamiasz testy, aby udowodnić, że faktycznie zawiodły, a następnie piszesz najprostszy kod, aby działał. Kompromis jest teraz (powinien) mieć zbiór tysięcy testów, który jest również kod, i jest tak samo prawdopodobne, jak kod produkcji, aby zawierać błędy. Będę szczery, nie jestem wielkim fanem TDD, głównie z tego powodu, ale to działa dla wielu programistów, którzy wolą pisać skrypty testowe niż dokumenty testowe -- niektóre testy lepsze to niż żadne. Połącz TDD z PP, aby uzyskać większe prawdopodobieństwo pokrycia testu i mniej błędów w skrypcie.

Jeśli Wszystko inne zawiedzie, niech programiści będą równi ze słoikiem przekleństw - za każdym razem, gdy programista złamie kompilację, muszą włożyć 20, 50, 100 dolarów (cokolwiek jest umiarkowanie bolesne dla Twoich pracowników) do słoika, który trafi do Twojego ulubionego (zarejestrowanego!) charity. Dopóki nie zapłacą, unikaj ich :)

Wszystkie żarty na bok, najlepszym sposobem, aby twój programista napisał testy jest nie niech programuje. Jeśli chcesz programistę, zatrudnij programistę . jeśli chcesz testy, zatrudnij testera. Zaczynałem jako młodszy programista 12 lat temu, robiąc testy, i to zmieniło się w moją ścieżkę kariery, i nie zamieniłbym go na nic. Solidny dział QA, który jest odpowiednio pielęgnowany i ma moc i mandat do ulepszania oprogramowania, jest tak samo cenny, jak twórcy piszący oprogramowanie w pierwszej kolejności.

To może być trochę bezduszne, ale sposób w jaki opisujesz sytuację brzmi, jakbyś musiał go zwolnić. Albo przynajmniej wyjaśnij: odmowa przestrzegania praktyk deweloperskich domu (w tym pisania testów) i sprawdzanie kodu buggy, który inni ludzie muszą wyczyścić, w końcu cię zwolnią.

Głównym powodem, dla którego młodsi inżynierowie / programiści nie zajmują dużo czasu na projektowanie i wykonywanie skryptów testowych, jest to, że większość certyfikatów CS nie wymaga tego w dużym stopniu, więc inne obszary inżynierii są dalej omawiane w programach uniwersyteckich, takich jak wzorce projektowe.

Z mojego doświadczenia wynika, że najlepszym sposobem, aby wprowadzić młodszych specjalistów w nawyk, jest uczynienie go częścią procesu wyraźnie. Oznacza to, że przy szacowaniu czasu, jaki powinna zająć iteracja, czasu projektowania, zapisu i / lub wykonaj przypadki powinny być włączone do tego oszacowania czasu.

Wreszcie, przegląd projektu skryptu testowego powinien być częścią przeglądu projektu, a rzeczywisty kod powinien być sprawdzony w przeglądzie kodu. To sprawia, że programista jest odpowiedzialny za prawidłowe testowanie każdej linii kodu, którą pisze, a starszy inżynier i współpracownicy są zobowiązani do przekazania informacji zwrotnej i wskazówek na temat kodu i napisanego testu.

Na podstawie Twojego komentarza "pokazanie, że projekt staje się prostszy" zakładam, że ćwiczycie TDD. Robienie przeglądu kodu po fakcie nie zadziała. Cała sprawa z TDD jest taka, że to projekt, a nie filozofia testowania. Jeśli nie napisał testów w ramach projektu, nie dostaniesz wiele korzyści z pisania testów po fakcie-zwłaszcza od młodszego programisty. Skończy na tym, że ominie wiele spraw na rogu, a jego kod nadal będzie gówniany.

Najlepiej jest mieć Bardzo cierpliwego starszego programisty, który usiądzie z nim i zaprogramuje parę. I nie przestawaj, dopóki się nie nauczy. Albo się nie uczy, w takim przypadku musisz przypisać go do zadania, do którego lepiej się Nadaje, ponieważ po prostu skończysz frustrując prawdziwych programistów.

Nie każdy ma taki sam poziom talentu i / lub motywacji. Zespoły programistyczne, nawet zwinne, składają się z ludzi z "Drużyny A" I "drużyny B". Członkowie zespołu A są tym, którzy projektują rozwiązanie, piszą cały nietrywialny kod produkcyjny i komunikują się z właścicielami firm - całą pracą, która wymaga myślenia nieszablonowego. Zespół B zajmuje się takimi sprawami, jak zarządzanie konfiguracją, pisanie skryptów, naprawianie kulawych błędów i wykonywanie prac konserwacyjnych - wszystkie prace, które mają ścisłe procedury, które mają niewielkie konsekwencje dla awarii.