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.
źródło
Odpowiedzi:
Spraw, aby było to niemożliwe, aby cokolwiek zwolnić bez naprawy testów.
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ść.
źródło
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.
źródło