Czy przegląd kodu powinien być wykonywany przed czy po testach jednostkowych

Dyskutuję z kolegą na temat tego, kiedy przeprowadzić przegląd kodu - przed lub po testach jednostkowych. Jaka jest najlepsza praktyka?

Niektóre czynniki, które możemy wziąć pod uwagę (może być ich więcej):

• Rozmiar zmiany kodu - duża zmiana oznacza, że ​​więcej recenzji wyniknie z przeglądu kodu. Jeśli te zmiany są większe niż, jeśli UT był przed przeglądem kodu, musisz powtórzyć większość swoich UT.
• Czas potrzebny na wykonanie testu jednostkowego
• Czy to nowa funkcjonalność czy naprawa błędu?

Zawsze powinieneś przeprowadzić test jednostkowy przed sprawdzeniem kodu i oto dlaczego

1. Jeśli Twój kod zostanie uszkodzony w sposób, który zostałby przechwycony przez testy jednostkowe, zmarnujesz czas drugiego programisty, angażując go w cykl czerwony / zielony / refaktor.
2. Testy pokazują innym deweloperom zamierzone użycie kodu, co ułatwia przeglądanie.
3. Testy powinny zostać przejrzane wraz z testowanym kodem na wypadek braku testów lub testów nie działają poprawnie.
4. Testy i przegląd kodu zwykle wychwytują różne problemy, przy niewielkim nakładaniu się na znalezione problemy. Testy jednostkowe nie denerwują się koniecznością ponownego testowania kodu, gdy recenzent znajdzie problemy, programiści denerwują się i prawdopodobnie nie zrobią tego lepiej za drugim razem.

Prawdopodobnie istnieją inne powody, ale te osobiście widziałem i doświadczyłem, wdrażając praktyki sprawdzania kodu w 3 różnych zespołach / firmach.

Edycja Oczywiście powyższe dotyczy czasów, gdy przegląd kodu jest krokiem w procesie tworzenia oprogramowania (wodospad lub zwinny). Jeśli pracujesz nad szczególnie dużą lub trudną sekcją kodu, możesz spojrzeć na nią w dowolnym momencie.

Recenzje kodu są wykonywane, gdy kod jest „gotowy”.

W mojej organizacji nasza definicja „zrobione” obejmuje testy jednostkowe (ponieważ dążymy do TDD), więc recenzje kodu zawierają pełny kod - a pełny kod obejmuje testy.

Testy również wymagają przeglądu i refaktoryzacji, więc sensowne jest, aby były częścią przeglądu kodu.

Testy należy uznać za część kodu do przejrzenia. Dlatego sensowne jest przejrzenie po zakończeniu testów.

Upewnij się, że testy również zostały przejrzane. Ma to kluczowe znaczenie dla tych, którzy dopiero zaczynają testy jednostkowe.

Upewnij się, że Twój zespół nie dociera do iniekcji zależności, ram izolacyjnych, makiet kontra odcinków, szwów, interakcji względem testów opartych na stanie i integracji vs testów jednostkowych.

Nie musisz wdrażać wyżej wymienionych tematów, ale powinieneś je zrozumieć.

Dobrze,

Zależy to od tego, co rozumiesz przez „test jednostkowy” ...

Jeśli był to test jednostkowy w stylu TDD, nie ma on znaczenia, ponieważ piszesz test podczas pisania kodu. W tym przypadku nie ma ciągłej poprawy jakości kodu: Refaktoryzacja ...

I

Jeśli był to klasyczny „test jednostkowy” [cokolwiek to znaczy, nie wiem, ale mam na myśli test po napisaniu kodów i wykonywany zwykle przez innych facetów], to główne kryteria są takie, jakich oczekujesz od widoku kodu i charakteru testów jednostkowych: jeśli chcesz szybkiego przeglądu opinii, podejmij działania i nie posiadaj automatycznego testu jednostkowego, musisz poczekać na test jednostkowy. Jeśli chcesz zidentyfikować dojrzałe problemy z przeglądem kodu i stopniowo zastosować rozwiązanie dla kolejnych iteracji, możesz to zrobić przed testem jednostkowym ...

Ale przecież osobiście, dla podglądu kodu, po lub późniejszy test jednostkowy nie jest dla mnie prawdziwym kryterium ...

Dlaczego przeglądamy kod? Aby uzyskać jakość kodu ... Zamiast bramki „kontroli jakości” wprowadź jakość do środowiska tworzenia oprogramowania…

Powiedziałbym, że bądźmy „zwinni” ... nie czekaj, aż kod zostanie ukończony, aby dokonać szybkiej, nieformalnej recenzji kodu: są programiści, z którymi i tematy, z którymi naprawdę możesz poczekać na cały kod + faza testowa do ukończenia ... ale

jeśli chodzi o naprawdę nowe tematy (zupełnie nowa funkcja, prawie badania, coś zupełnie nowego dla zespołu), wczesna weryfikacja kodu, nie trać czasu: poproś współpracownika, by od czasu do czasu rzucił okiem: izolacja jest ważnym czynnikiem niepowodzenia w tym przypadku.

jeśli programista jest także nowy w zespole, sprawdź kod wcześniej i być może często .

a przy okazji, testy jednostkowe również wymagają przeglądu kodu.