Gdzie przeprowadzić test negatywny?

Właśnie zmieniłem ustawienia gałęzi w moim repozytorium GitHub, tak więc moja [następna] gałąź wymaga przekazania kompilacji CI przez żądanie ściągnięcia.

Następnie odbyła się dyskusja z kilkoma członkami zespołu na temat nieudanych testów.

Dla kontekstu ...

Repozytorium ma gałąź [master], do której PR jest wprowadzany tylko wtedy, gdy jest wydanie, więc [master] zawiera kod z ostatniej wersji, niezależnie od tego, czy jest to major, minor, hotfix, beta, alpha / kompilacja przedpremierowa.

Gałąź [next] jest gałęzią „domyślną”, w której zamierzamy zachować kod „gotowy do wydania”; technicznie rzecz biorąc, gałąź ta może być w dowolnym momencie PR [master] i zwolniona.

Poszczególne widelce mają własne oddziały deweloperów, a autorów PR do [dalej].

Kiedy przeglądam nietrywialny PR, połączę gałąź programisty autora z moją gałęzią „recenzowania”, a jeśli zobaczę rzeczy, które mogę szybko naprawić, zatwierdzę / wypchnę zmiany i nowe (czasem nieudane) testy oraz PR z powrotem do działu twórców; kiedy scalą moje zmiany, sprawią, że nowe testy zakończone niepowodzeniem przejdą, a następnie wypchną, ich PR zsynchronizuje, a następnie połączę PR w [następny].

Ale to pytanie nie dotyczy zdania testów, dotyczy tych, które nie zdały egzaminu .

Niepowodzenie testów dokumentuje, co należy naprawić.

Znane błędy powinny mieć napisane testy, abyśmy wiedzieli, co nie działa.

Technicznie robi to także lista problemów GitHub (filtrowana pod kątem błędów i / lub krytycznych etykiet ). Czy jest to dobra praktyka, aby również mieć kilka braku testów błędów dokumentu?

Upadającego build na [dalej] oznaczałoby, że nie jesteśmy gotowi zwolnić, ale wtedy ... „bycia release-ready” jest trochę jak „gotowość”, aby mieć dzieci - nigdy nie jesteś całkiem gotowy do tego, a coś gdzieś (o różnym znaczeniu) nieuchronnie pójdzie nie tak z wydaniem.

Dlatego zawsze pchamy testy z wynikiem pozytywnym do [dalej]. Gdzie zatem przeforsować nieudane testy? Mam na myśli, poza procesem PR / recenzji?

Na przykład użytkownik zgłasza nowy błąd na liście problemów i chciałbym napisać dla niego niepoprawny pakiet testowy - aby określić, co należy zrobić i gdzie, co ułatwia nowym współautorom i ostatecznie PR poprawkę.

Gdzie powinienem przeprowadzać te nieudane testy? A może dobrym pomysłem jest wypuszczanie gdziekolwiek nieudanych testów?

W tej sytuacji oznaczę niepowodzenia testów jako „zignorowane” - w ten sposób nadal masz test, abyś wiedział, co musisz naprawić w przyszłości, ale nie skończy się to na zepsutych kompilacjach .

Jeśli również oznaczysz każdy test odnośnikiem do śledzenia problemów w celu rozwiązania problemu, daje to łatwy sposób na powiązanie rzeczy.

Pełne ujawnienie: jestem jednym z uczestników dyskusji.

Główna gałąź repozytorium nie jest jego główną gałęzią. Scalanie w master nie służy żadnemu „faktycznemu celowi”, a gałąź ta nie robi rzeczy, które gałąź powinna robić (czyli przenosić ).
Nadużywasz tej gałęzi jako Tag do najnowszej wersji.

Zamiast korzystać z gałęzi, użyj tagu. Kiedy chcesz wydać, wykonaj niezbędne kroki w „gałęzi wydania”, podobnie jak gałęzi tematu. Następnie scalasz to w [next] i umieszczasz na nim Tag.

Rola, którą [następnie] spełnia, jest odgałęzieniem głównym. Jest tam tylko kod gotowy do wydania. Wszystko inne byłoby gałęzią [rozwoju]. Gałąź rozwoju zawiera prace, które należy ustabilizować . Oznacza to: usuń [master], zmień przeznaczenie [next] w sposób, w jaki już to zrobiłeś i utwórz kolejną gałąź dla „mniej stabilnej” pracy.

Ponieważ jest to raczej wyjątek niż reguła, że ​​muszą istnieć niepomyślne testy przypominające o zaległych błędach, tworzenie i niszczenie tej mniej stabilnej gałęzi nie powinno stanowić problemu