Jak utworzyć środowisko, w którym testy naprawcze są traktowane priorytetowo?

Jestem inżynierem oprogramowania w średniej wielkości firmie. Mamy dość solidną platformę testową działającą w TeamCity. Wykonuje testy jednostkowe przy każdym zameldowaniu oraz codzienny test jednostkowy / przebieg BVT.

Problem polega na tym, że mamy wiele zepsutych testów jednostkowych.

Dość często podnoszę bezcelowość testów jednostkowych, jeśli są one ciągle łamane i nieobsługiwane. Brak możliwości sprawdzenia, czy zmiana spowodowała regresję, usuwa większość wartości platformy do testów jednostkowych.

Chciałbym zasiać ziarno, które stworzy kulturę dobrych nawyków - ustalanie testów, gdy zostaną złamane, postrzeganie ich jako cenne, priorytetowe ustalanie testów wraz z innymi pracami.

Próbowałem przekupstwa (wypieków!), Po prostu pytałem i rozmawiałem z liderami zespołu. Wszyscy mówią, że to dobry pomysł, ale widzę, że tylko on coś z tym robi.

Jaki jest najlepszy sposób na rozpoczęcie zachęcania innych do naprawiania testów i nadawania priorytetu naprawom testowym w ich sprintach?

Jeśli istnieje mniej subiektywny sposób, by o to zapytać, chętnie przyjmę wszelkie wskazówki.

— Codeman
źródło

automatyczny pistolet celowniczy wymierzony w faceta, który łamie kompilację ...

— maniak zapadkowy

W rzeczywistości mamy automatyczny pistolet nerfowy ... ale kompilacja nie jest zepsuta, tylko testy jednostkowe :)

— Codeman

Przerwanie testów jednostkowych powinno oznaczać przerwanie kompilacji. ;)

— Jeroen Vannevel

@ Ᶎσᶎ: Wpis jest ważny, ale nie można uzyskać wpisowego w celu rozwiązania problemu, dopóki ludzie nie będą świadomi problemu. W takim przypadku wpisowe muszą początkowo pochodzić od kierowników zespołów i menedżerów. Wpis deweloperów może nastąpić później i oczywiście nastąpi, gdy system kompilacji zostanie skonfigurowany tak, aby poszczególni programiści płacili za własne błędy.

— Aaronaught

Jeśli pączki się nie powiodły, toast. :-)

— Ross Patterson

Odpowiedzi:

Spraw, aby było to niemożliwe, aby cokolwiek zwolnić bez naprawy testów.

Niepowodzenie kompilacji, jeśli jakiekolwiek testy zakończą się niepowodzeniem
Niepowodzenie kompilacji, jeśli jakiekolwiek testy zostaną zignorowane.
Błąd kompilacji, jeśli zasięg testu spadnie poniżej określonego poziomu (więc ludzie nie mogą po prostu usunąć testów, aby obejść ten poziom).
Użyj serwera CI, aby wykonać kompilacje wersji i zezwalaj tylko na kompilacje z dropu kompilacji serwera na UAT / staging / production / cokolwiek.

Faktem jest, że jeśli twoja kompilacja jest przerywana przez więcej niż około 15 minut na raz (i obejmuje to nieudane testy), to nie robisz ciągłej integracji .

„Opcja nuklearna” polega na tym, aby serwer kontroli źródła odmawiał zatwierdzania / sprawdzania danych przez użytkownika innego niż ten, który złamał kompilację. Oczywiście administrator musi być w stanie tymczasowo to obejść, jeśli dana osoba wyjedzie na wakacje - ale jeśli wszyscy wiedzą, że cały zespół jest spieprzony, dopóki nie naprawią swoich testów, szybko to rozwiążą.

Dobrą zasadą (która jest jeszcze lepsza, gdy jest zautomatyzowana) jest przywrócenie źródła do ostatniego znanego stabilnego zatwierdzenia po 15 minutach niepowodzenia kompilacji. Innymi słowy, jeśli nie możesz tego naprawić lub nie wiesz, co spowodowało przerwanie kompilacji lub testu, to cofnij go i działaj lokalnie, aż zostanie rozwiązany - nigdy nie zmuszaj innych programistów do poruszania kciukami, podczas gdy ty mierzysz problem, na którym im nie zależy.

PS Jeśli masz już wiele testów zakończonych niepowodzeniem, możesz użyć „progu końcowego” w CI. Skonfiguruj tak, aby kompilacja zakończyła się niepowodzeniem tylko wtedy, gdy wystąpi więcej niepowodzeń testowych niż ostatnim razem. To, wraz z regułą zasięgu, zmusi programistów do ostatecznej poprawy sytuacji testowej, jeśli będą chcieli móc dalej działać.

PPS Zdaję sobie sprawę, że niektórym może to wydawać się drakońskie, ale to wszystko zależy od twojej kultury. Jeśli dojdziesz do punktu, w którym ludzie po prostu nie pozostawiają zepsutej kompilacji lub testów nie powiodło się (mój zespół prawie nigdy tego nie robi, chociaż czasami muszę im przypominać), nie musisz przestrzegać najsurowszych zasad. Chociaż IMO zawsze powinieneś zawieść kompilacji na uszkodzonym teście jednostkowym. Testy integracji / przeglądarki mogą czasami zawieść.

— Aaronaught
źródło

Chociaż wszystkie twoje wskazówki techniczne są przydatne, myślę, że najcenniejszą częścią twojej odpowiedzi jest to, że „To cała twoja kultura”, ponieważ bardziej niż problem dyscypliny, jest to problem postrzeganej użyteczności testu. Wolę umieścić go na pierwszym planie niż w PPS

— user40989

@ user40989: Słyszę cię. Kultura jest jednak czymś, co musisz kultywować. Jeśli chcesz, aby ludzie rozumieli, jak ważne są testy, czasami musisz to zrobić, aby ludzie nie mogli ich zignorować. Gdy ludzie przyzwyczają się do wysokiego poziomu pokrycia kodu i zielonych testów, nie będą chcieli wracać, a wtedy wasi programiści wymuszą to dla nowych rekrutów. Mam nadzieję, że. Pomocny jest zespół prowadzący i / lub budujący zespół analny. :)

— Aaronaught

FWIW: Cały nasz proces wydawania jest teraz zautomatyzowany i ludzie nie pomyśleliby o zerwaniu testów. Kierownik zespołu dokonuje scalenia w celu opanowania, a następnie rozpoczyna kompilację wersji i wysyła żądanie promocji do sysadminów, którzy dosłownie naciskają przycisk, aby wdrożyć z artefaktów kompilacji i uruchomić automatyczne testy przeglądarki i interfejsu API. Nikt nigdy nie narzeka na ten proces, ponieważ oszczędza on czas - zwykliśmy spędzać 2 tygodnie na staraniach o wydanie, teraz jest to po prostu fala ręczna. Mam na myśli kultywowanie kultury - wszyscy wiedzą, że dodatkowe 2 minuty na naprawę testu pozwolą zaoszczędzić 2 godziny później.

— Aaronaught

Nieudane testy jednostek nie są problemem. Są symptomem .

Prawdziwy problem tkwi w kulturze. Musisz delikatnie stąpać: tu będą smoki . Nie możesz sam zmienić kultury, a bycie piskliwym kołem ostatecznie uczyni cię wyrzutkiem. Dosłownie

Sugeruję, że jeśli spróbujesz znaleźć osobę starszą, która będzie popierać sprawę i prowadzić. Jeśli to się nie powiedzie, spróbuj podnieść go na ogólnym spotkaniu programistów, bez wskazywania palcami i wywoływania nazwisk. Inną alternatywą jest wzięcie odpowiedzialności za wykonanie właściwej pracy: po prostu napraw kilka testów za każdym razem, gdy odprawisz się. Zachowaj na ścianie wykres pokazujący, ile testów zakończyło się niepowodzeniem w czasie. Inni to zobaczą: może włączą się.

Nie ma łatwej odpowiedzi.

— andy256
źródło

Bycie piskliwym kołem sprawiło, że stałem się liderem zespołu. Może coś było nie tak z twoim piskiem? Jednak z całą powagą dotyczy to zupełnie innego problemu kulturowego, nie z zespołem twórców, ale z zarządem firmy. Jeśli reakcją kierownictwa na płonący ogień jest założenie okularów przeciwsłonecznych, to po prostu wynoś się. Ale jeśli faktycznie jesteś sklepem deweloperskim , w przeciwieństwie do korporacyjnego działu IT, który produkuje oprogramowanie z centrum kosztów, istnieje duże prawdopodobieństwo, że menedżerom zależy na tym, jak często i bezpiecznie możesz wprowadzać na rynek.

— Aaronaught