Czy testy jednostkowe powinny być przechowywane w repozytorium?

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?

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.

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ą.

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)

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.

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).

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.