Gdzie przeprowadzić test negatywny?

14

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 i / lub 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?

Mathieu Guindon
źródło
@PhilipKendall dobry punkt! wciąż dopracowujemy nasz proces; Nie podoba mi się, w jaki sposób VS wypycha „ignorowane” testy razem z „nieprzekonującymi” testami - jeśli jeden z testów niższego poziomu zawiedzie, nie chcemy, aby połowa testów zawiodła, więc robimy je niejednoznaczne, gdy warunki wstępne nie są spełnione ; powoduje to, że testy zgłaszają niepowodzenie z właściwych powodów i „niejednoznaczne”, gdy nie mogą przetestować tego, dla czego zostały napisane. Nie mamy ich dużo (już), więc zignorowanie ich może być opcją ... ale czy test nie powiedzie się, jeśli zostanie zignorowany ?
Mathieu Guindon
Dlaczego część procesu recenzji wymaga napisania kodu? Jeśli zobaczysz błąd, komentujesz go w PR i opcjonalnie odrzucasz PR.
James
@James dobrze, lubię pisać kod ... poza tym, gdy dołącza się więcej współautorów, robię coraz więcej prac związanych z utrzymaniem GitHub i PR (public relations) niż faktyczne kodowanie!
Mathieu Guindon

Odpowiedzi:

11

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.

Philip Kendall
źródło
4

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

Vogel612
źródło
1
Posiadanie najnowszej wersji w [master] ułatwia odgałęzienie ostatniej wersji w celu wydania poprawki; wtedy poprawkę można PR dodać do [dalej], a stamtąd do każdej gałęzi deweloperów .. czy coś mi brakuje?
Mathieu Guindon
2
Możesz po prostu git checkout -b HotFix ReleaseTag(to znaczy, jeśli dobrze pamiętam gałąź, która poprawnie tworzy składnię kasy). To powinno utworzyć gałąź HotFix z ReleaseTag
Vogel612