Czy powinienem celowo przerywać kompilację, gdy w produkcji zostanie wykryty błąd?

Wydaje mi się rozsądne, że jeśli poważny błąd zostanie wykryty przez użytkowników końcowych, należy dodać test jednostkowy, który go nie obejmuje, celowo przerywając kompilację, dopóki błąd nie zostanie naprawiony. Moim uzasadnieniem jest to, że kompilacja powinna była zawieść przez cały czas , ale nie było to spowodowane nieodpowiednim automatycznym zasięgiem testów.

Kilku moich kolegów nie zgodziło się ze stwierdzeniem, że nie powiodło się sprawdzenie testu jednostkowego. Zgadzam się z tym punktem widzenia w zakresie normalnych praktyk TDD, ale uważam, że błędy produkcyjne powinny być traktowane inaczej - w końcu dlaczego chcesz pozwolić kompilacja pozwalająca odnieść sukces ze znanymi wadami?

Czy ktoś jeszcze sprawdził strategie radzenia sobie z tym scenariuszem? Rozumiem, że celowe przerwanie kompilacji może być szkodliwe dla innych członków zespołu, ale to całkowicie zależy od tego, jak korzystasz z gałęzi.

Nasza strategia to:

Sprawdź test zakończony niepowodzeniem, ale opatrz go adnotacją @Ignore("fails because of Bug #1234").

W ten sposób test jest gotowy, ale kompilacja się nie psuje.

Oczywiście zanotowano ignorowany test w db db, więc @Ignorejest on usuwany po naprawieniu testu. Służy to również jako łatwe sprawdzenie poprawki błędu.

Celem przełamania kompilacji po nieudanych testach nie jest jakoś wywarcie presji na zespole - to ostrzeżenie go o problemie. Gdy problem zostanie zidentyfikowany i zapisany w bazie danych błędów, nie ma sensu uruchamiać testu dla każdej kompilacji - wiesz, że zakończy się niepowodzeniem.

Oczywiście błąd powinien zostać naprawiony. Ale zaplanowanie poprawki jest decyzją biznesową, a więc tak naprawdę nie jest troską dewelopera ... Dla mnie, gdy błąd zostanie zgłoszony w DB błędu, nie jest to już mój problem, dopóki klient / właściciel produktu nie powie mi, że chce go naprawić .

Dlaczego chcesz pozwolić kompilacji na powodzenie ze znanymi defektami?

Ponieważ czasami masz ograniczenia czasowe. Lub błąd jest tak niewielki, że tak naprawdę nie warto opóźniać wysyłki produktu na kilka dni, aby przeprowadzić test jednostkowy i naprawić.

Jaki jest sens celowego przerywania kompilacji za każdym razem, gdy znajdziesz błąd? Jeśli go znalazłeś, napraw go (lub przypisz to osobie, która go naprawi), nie przeszkadzając całemu zespołowi. Jeśli chcesz pamiętać o naprawieniu błędu, musisz oznaczyć go jako bardzo ważny w systemie śledzenia błędów.

Istnieją testy, aby upewnić się, że nie (ponownie) wprowadzasz problemów. Lista nieudanych testów nie zastępuje systemu śledzenia błędów. W POV istnieje pewna poprawność, że nieudane testy nie tylko wskazują na błędy, ale także wskazują na niepowodzenie procesu rozwoju (od nieostrożności do źle zidentyfikowanej zależności).

„Przerwij kompilację” oznacza zapobieganie pomyślnemu ukończeniu kompilacji . Niepowodzenie testu tego nie robi. Wskazuje to, że kompilacja ma znane wady, co jest dokładnie poprawne.

Większość serwerów kompilacji śledzi status testów w czasie i przypisuje inną klasyfikację testowi, który nie powiódł się, ponieważ został dodany w porównaniu z regresją (test, który przeszedł pomyślnie i już go nie robi), a także wykrywa wersję, w której nastąpiła regresja.

Argumentowałbym, że test negatywny powinien zostać dodany, ale nie jawnie jako „test negatywny”.

Jak podkreśla @BenVoigt w swojej odpowiedzi , nieudany test niekoniecznie „psuje kompilację”. Wydaje mi się, że terminologia może się różnić w zależności od zespołu, ale kod nadal się kompiluje, a produkt może zostać dostarczony z testem zakończonym niepowodzeniem.

W tej sytuacji powinieneś zadać sobie pytanie:

Jakie testy mają zostać wykonane?

Jeśli testy są po to, aby wszyscy czuli się dobrze z kodem, wówczas dodanie testu zakończonego niepowodzeniem tylko po to, aby wszyscy poczuli się źle z powodu kodu, nie wydaje się produktywne. Ale w takim razie, jak wydajne są testy?

Twierdzę, że testy powinny odzwierciedlać wymagania biznesowe . Jeśli więc zostanie znaleziony „błąd” wskazujący, że wymaganie nie jest właściwie spełnione, oznacza to również , że testy nie odzwierciedlają poprawnie lub w pełni wymagań biznesowych.

To jest błąd, który należy naprawić w pierwszej kolejności. Nie dodajesz „testu zakończonego niepowodzeniem”. Jesteś poprawiania testów aby być bardziej dokładnym odzwierciedleniem wymagań biznesowych. Jeśli kod nie przejdzie tych testów, to dobrze. Oznacza to, że testy wykonują swoją pracę.

Priorytet ustalenia kodu ma zostać określony przez firmę. Ale czy dopóki testy nie zostaną naprawione, czy rzeczywiście można ustalić ten priorytet? Firma powinna być uzbrojona w wiedzę na temat tego, co dokładnie zawodzi, jak się zawodzi i dlaczego zawodzi, aby podejmować decyzje dotyczące priorytetów. Testy powinny to wskazać.

Posiadanie testów, które nie są w pełni zaliczone, nie jest złą rzeczą. Tworzy wielki artefakt znanych problemów, które należy traktować priorytetowo i odpowiednio nimi traktować. Problemem są jednak testy, które nie są w pełni testowane . Podważa wartość samych testów.

Mówiąc inaczej: kompilacja jest już zepsuta. Ty decydujesz tylko, czy zwrócić uwagę na ten fakt.

W naszym zespole ds. Automatyzacji testów sprawdzamy testy zakończone niepowodzeniem, pod warunkiem, że zakończą się one niepowodzeniem z powodu wady produktu, a nie wady testu. W ten sposób mamy dowód dla zespołu programistów, że hej, oni go złamali. Zerwanie z kompilacją jest bardzo rozczarowane, ale to nie to samo, co sprawdzanie w doskonale kompilowalnych, ale nieudanych testach.

Pisanie testu, o którym wiesz, że się nie powiedzie, dopóki błąd nie zostanie naprawiony, to dobry pomysł, jest to podstawa TDD.

Złamanie kompilacji to zły pomysł. Dlaczego? Ponieważ oznacza to, że nic nie może się poruszać, dopóki nie zostanie naprawione. Zasadniczo blokuje wszystkie inne aspekty rozwoju.

Przykład 1
Co zrobić, jeśli twoja aplikacja jest bardzo duża i zawiera wiele składników? Co się stanie, jeśli nad tymi komponentami pracują inne zespoły z własnym cyklem wydawniczym? Twardy! Muszą czekać na naprawę błędu!

Przykład 2
Co zrobić, jeśli pierwszy błąd jest trudny do naprawienia, a znajdziesz inny błąd o wyższym priorytecie? Czy również przerywasz kompilację drugiego błędu? Teraz nie możesz budować, dopóki oba nie zostaną naprawione. Stworzyłeś sztuczną zależność.

Nie ma logicznego powodu, dla którego niepowodzenie testu powinno zatrzymać kompilację. Jest to decyzja, którą zespół deweloperów musi podjąć (być może podczas dyskusji zarządczej), wyważając zalety i wady wydania kompilacji ze znanymi błędami. Jest to bardzo powszechne w rozwoju oprogramowania, prawie całe główne oprogramowanie jest wydawane z przynajmniej niektórymi znanymi problemami.

Zależy to od roli, jaką mają odgrywać testy i jaki wpływ mają ich wyniki na przyjęty system / proces kompilacji. Moje rozumienie łamania kompilacji jest takie samo jak Bena, a jednocześnie nie powinniśmy świadomie sprawdzać kodu, który psuje istniejące testy. Jeśli te testy pojawią się „później”, może być „w porządku” ich zignorowanie, aby uczynić je mniej niepotrzebnie szkodliwymi dla innych, ale uważam, że taka praktyka ignorowania nieudanych testów (tak, aby zdawały się zdać) jest raczej niepokojąca (szczególnie w przypadku testów jednostkowych), chyba że istnieje sposób wskazania takich testów jako czerwonego ani zielonego.

Zależy to oczywiście od błędu, ale ogólnie, jeśli coś poszło nie tak, co nie zostało wykryte podczas testowania ręcznego lub automatycznego, oznacza to, że masz lukę w zasięgu. Zdecydowanie zachęciłbym do znalezienia głównej przyczyny i umieszczenia jednostkowego przypadku testowego nad problemem.

Jeśli jest to problem produkcyjny, który jest planowany dla poprawki z gałęzi serwisowej, musisz także upewnić się, że poprawka działa na linii głównej i że programista nie może omyłkowo usunąć poprawki z nadgorliwym rozwiązaniem konfliktu scalania .

Ponadto, w zależności od polityki wersji, obecność nowo zaktualizowanych testów jednostkowych może pomóc potwierdzić, że programista naprawił problem, a nie tylko go zmienić [(problem czy testy?)], Chociaż zależy to od zakodowania poprawne wymagania w nowych testach jednostkowych.

Jednym z problemów związanych z dodawaniem testu kompilacji „know-to-fail” jest to, że Twój zespół może mieć zwyczaj ignorowania testów zakończonych niepowodzeniem, ponieważ oczekuje, że kompilacja się nie powiedzie. Zależy to od systemu kompilacji, ale jeśli test zakończony niepowodzeniem nie zawsze oznacza „coś się właśnie zepsuło”, łatwo jest poświęcić mniej uwagi testom zakończonym niepowodzeniem.

Nie chcesz pomagać swojemu zespołowi w tym sposobie myślenia.

Zgadzam się więc z sleske, że powinieneś dodać test, ale zaznacz go jako „zignorowany” na potrzeby automatycznej kompilacji, dopóki błąd nie zostanie naprawiony.

Chociaż uważam, że powinieneś w jakiś sposób „sprawdzić” błąd jako test, aby po jego naprawieniu nie powtórzył się on i w jakiś sposób nadać mu priorytet, myślę, że najlepiej nie przerywać kompilacji (/ testów) . Powodem jest to, że późniejsze zobowiązania do rozbijania kompilacji zostaną ukryte za zepsutym testem. Dlatego sprawdzając uszkodzony test pod kątem tego błędu, żądasz, aby cały zespół odłożył na bok swoją pracę, aby naprawić ten błąd. Jeśli tak się nie stanie, możesz skończyć z łamaniem zatwierdzeń, których nie da się prześledzić.

Dlatego powiedziałbym, że lepiej jest wykonać go jako test w toku, a priorytetem w twoim zespole jest brak testów w toku.

Inną opcją jest sprawdzenie testu zakończonego niepowodzeniem w oddzielnej gałęzi w systemie kontroli źródła. W zależności od praktyk może to być wykonalne lub nie. Czasami otwieramy nowy oddział do bieżącej pracy, na przykład naprawiania błędu, który nie jest trywialny.