Czy testy jednostkowe powinny być przechowywane w repozytorium?

50

Jestem rozwijającym się programistą, który w końcu wdraża testy jednostkowe dla biblioteki, którą przechowuję w GitHub.

Przyszło mi do głowy, że mogę dołączyć pakiety testowe do repozytorium, ale kiedy rozglądam się za innymi projektami, włączenie testów wydaje się być trafione lub nieudane.

Czy to jest uważane za złą formę? Czy pomysł jest taki, że użytkownicy są zainteresowani tylko działającym kodem i że i tak będą testować w swoich ramach?

version-control unit-testing

— parisminton
źródło

13

Dlaczego nie? Testy powinny towarzyszyć projektowi lub są ledwo bezużyteczne.

61

Fakt, że niektóre projekty nie zawierają testów jednostkowych w swoim repozytorium, jest bardziej prawdopodobne ze względu na brak tych testów w pierwszej kolejności.

— prasopes

4

Są one budowane osobno, ale poza tym testy U są ściśle powiązane z kodem. Aby zapewnić spójność, musi istnieć pewien rodzaj zarządzania zależnościami. Czy to umieszczanie ich w tym samym repozytorium, pod-repozytorium lub utrzymywanie kontrolowanego przez wersję „linku” do testowania repozytorium itp.

— MaR

2

@stoupa ma całkowitą rację: dobrze byłoby założyć, że jest gdzieś ukryta wspaniała pamięć testów, ale w prawdziwym świecie programiści są leniwi.

— Cascabel

2

Zauważ, że uważam za dobry pomysł wyłączenie kompilacji klas testowych w skrypcie kompilacji.

— user606723,

119

Zdecydowanie powinieneś umieścić swoje testy w repozytorium. Testy są moim zdaniem częścią kodu i mogą ogromnie pomóc innym w jego zrozumieniu (jeśli są dobrze napisane). Poza tym mogą pomagać innym w zmianie lub współtworzeniu bazy kodu. Dobre testy mogą dać ci pewność, że twoje zmiany nie spowodują przypadkowego zniszczenia.

Kod testowy powinien być jednak dobrze oddzielony od kodu produkcyjnego. Na przykład Maven osiąga to poprzez umieszczenie kodu produkcyjnego i testowego w różnych folderach. Pytanie „czy ten plik jest częścią produkcji lub kodu testowego” nigdy nie powinno się pojawić.

Osobiście nie piszę testów jednostkowych używanych bibliotek we własnym kodzie. Spodziewam się, że będą działać (przynajmniej kiedy używam wersji wydanej, chociaż oczywiście mogą pojawić się błędy). Dostaje pewne pokrycie w testach integracyjnych, ale to nie wystarczy.

— ftr
źródło

1

Jako kolejny przykład spójrz na folder testowy ipython . Jeśli ktoś to sprawdzi, bez względu na to, gdzie go umieści, względne linki do testów są nadal prawdziwe. Testowanie go jest trywialne, co jest ważne przy ustalaniu, czy nowa maszyna deweloperska jest poprawnie skonfigurowana.

— Spencer Rathbun

Testy są nie tylko częścią kodu, ale także częścią dokumentacji, a często częścią specyfikacji. Testy (które uruchamiają się i kończą) są „żywą dokumentacją”.

— Michał Wielkanocny

54

Jeśli nie uwzględnisz testów jednostkowych w zameldowanym kodzie źródłowym, to:

w jaki sposób ktoś, kto pobiera i tworzy własną kopię tego kodu, sprawdza, czy działa on zgodnie z przeznaczeniem? Błędy kompilatora i biblioteki są rzadkie, a błędy danych (szczególnie te, które nie uniemożliwiają kompilacji kodu źródłowego) są jeszcze rzadsze, ale na pewno mogą się pojawiać, szczególnie gdy nie można dyktować środowiska kompilacji w stopniu, w jakim pracodawca może dyktować, które narzędzia są używane.
Jak zamierzasz odzyskać testy, jeśli coś się stanie z lokalną kopią kodu źródłowego?
w jaki sposób nowy programista sprawdzi, czy ich zmiany niczego nie psują w istniejącej bazie kodu?

Podsumowując, uważam, że nie uwzględnianie testów jednostkowych zapisanych w oficjalnym repozytorium kodu źródłowego jest bardzo złą rzeczą.

— CVn
źródło

7

Oczywiście powinieneś umieścić testy jednostkowe w repozytorium z kilku powodów:

łatwo jest powrócić do poprzedniej wersji
inne osoby pracujące nad projektem mają również dostęp do testów jednostkowych
niektóre osoby uważają testy jednostkowe za część dokumentacji (TDD i BDD)

— BЈовић
źródło

6

Jeśli istnieje jakaś szansa na uruchomienie ich na innym komputerze, zdecydowanie je dołącz. Powinny być budowane osobno, więc użytkownicy nie muszą i mogą mieć dodatkowe zależności, ale zdecydowanie powinny zostać uwzględnione.

Podejrzewam, że większość projektów, które nie zawierają testów w repozytorium, po prostu ich nie ma.

Może istnieć powód, aby testy były oddzielnym modułem, aby można było łatwo uruchamiać nowe testy ze starszym kodem. Przydałoby się to w przypadku bibliotek stabilnych API lub testów czarnej skrzynki za pomocą wiersza poleceń; przydatność skompilowanych języków, w których nowe testy prawdopodobnie nie będą się kompilowały ze starszym kodem, jest ograniczona.

— Jan Hudec
źródło

5

Absolutnie. Dodatkowe punkty bonusowe w tym przypadku to możliwość śledzenia, czy wersja X pliku źródłowego jest zgodna z wersją Y testu. Innymi słowy, musisz mieć możliwość powrotu do poprzedniej wersji i pobrania odpowiednich testów zaprojektowanych dla tej wersji (w przypadku zmiany interfejsu API lub czegoś takiego).

— zaraz
źródło

3

Właśnie skończyłem czytać „Brownfield Application Development in .Net” , a to zapewnia doskonałą poradę dotyczącą struktury aplikacji, w tym kontroli źródła oraz gdzie / jak / dlaczego włączyć testy jednostkowe (szczególnie w obszarze ciągłej integracji) . Jeśli jesteś programistą .Net, polecam to.

— seanfitzg
źródło