Czy dane testowe powinny być sprawdzane w kontroli wersji?

40

Piszę kod testowy dla funkcji przetwarzającej pliki PDF. Podstawowa idea testów polega na tym, że kieruję je w stronę wybranych plików PDF, które przetwarzam i sprawdzam, czy wyniki są zgodne z oczekiwaniami.

Moje pytanie brzmi: gdzie powinienem przechowywać te duże pliki PDF? Czy powinienem sprawdzić je w kontroli wersji wraz z kodem? Lub umieścić je gdzie indziej? Oczywiście kod testowy jest bezużyteczny bez plików PDF (lub nawet z różnymi plikami PDF), ale mimo to umieszczenie ich w naszym repozytorium wydaje się niewłaściwe.

testing version-control data

— Swiftheart
źródło

2

możliwy duplikat Czy testy jednostkowe powinny być przechowywane w repozytorium?

— CVn

19

@ MichaelKjörling:Tests != Test Data

— Robert Harvey

4

@RobertHarvey Prawda, ale jeśli dane testowe są wymagane, aby test zadziałał, uważam, że należy go uznać za część testu. Takie jest również podejście przyjęte przez wszystkie trzy odpowiedzi, o ile je rozumiem.

— CVn

84

Twój system kontroli wersji powinien zawierać wszystko, czego potrzebuje do zbudowania, kompilacji, przetestowania i spakowania aplikacji do dystrybucji (np. MSI, RPM). Chciałbym również argumentować, że konfiguracje kompilacji i inne skrypty również powinny mieć kontrolę wersji.

Powinienem być w stanie sprawdzić projekt i mieć pełne środowisko kompilacji, kompilacji i testowania.

Istnieją dwa podejścia do sprawdzania danych testowych. Najpierw możesz sprawdzić same dane testowe (w tym przypadku pliki PDF). Po drugie, możesz wpisać dane źródłowe, które można wykorzystać do wygenerowania danych testowych (jeśli dotyczy). Może to być skrypt SQL załadowany do pustej bazy danych zawierającej dane testowe lub plik tekstowy, który można skompilować do pliku PDF lub innego pliku.

Inni mogą nie zgodzić się na sprawdzenie wszystkiego w zakresie kontroli wersji, ale z mojego doświadczenia zawodowego przekonałem się, że kluczowe znaczenie ma zapewnienie, że pełne środowisko będzie mogło zostać odbudowane od podstaw.

20

Tak. Absolutnie tak. Jest rok 2014, nie ma żadnego uzasadnienia dla używania kontroli wersji, która nie obsługuje płynnie plików binarnych.

— Kilian Foth,

4

Zgadzam się, ale zdecydowanie chcesz uniknąć sytuacji, w której sprawdzasz również śmieciowe przedmioty. Na przykład, jeśli dane testowe zawierają folder „wyjściowy”, który zawiera wszystkie pliki pdf wygenerowane przez testy, nie będziesz chciał umieszczać tego w repozytorium. Ale zgadzam się, że same testy powinny być częścią repozytorium, a także wszelkich pakietów potrzebnych do jego uruchomienia.

— Kenneth Garza

1

@KennethGarza To naprawdę nie jest trudne. Zasadniczo należy dołączyć wszelkie oryginalne treści (kod źródłowy, testowy kod źródłowy, dane testowe, media, [rzeczywistą] dokumentację, biblioteki stron trzecich, skrypty kompilacji, skrypty narzędziowe, skrypty konwersji itp.), A wszystkie dane które można wygenerować w rozsądnym czasie na podstawie oryginalnych danych, nie powinno być. Poza tym, biorąc pod uwagę, że są to wyniki testowe, prawdopodobnie mają one sens tylko po uruchomieniu testów samodzielnie, w przeciwnym razie nie testujesz swojego programu, testujesz zdolność oprogramowania VCS do zachowania integralności twoich plików :)

— Thomas

1

@ MarnenLaibow-Koser: projekt, nad którym pracowałem nad wykryciem awarii elektrycznej w wszczepionych elektrodach stymulatora, miał zestaw testowy o pojemności ponad 40 GB. Nie istnieje VCS, w którym radzenie sobie z tym nie jest obrzydliwe. Posiadanie dwóch repozytoriów jest samo w sobie problemem administracyjnym, ale czasem może być lepszym wyborem.

— whatsisname

1

@ MarnenLaibow-Koser masz to. Testy integracyjne znajdują się w osobnym repozytorium i jeśli użytkownik chce uruchomić go lokalnie, zarządzanie zależnościami pobierze dla niego plik zip i rozpakuje go. Zwykle serwer / farma ciągłej integracji ma za zadanie wykonać test integracji i zapobiegnie scaleniu gałęzi funkcji do czasu przejścia testów integracji.

— user482745,

15

Jeśli testy są bezużyteczne bez przygotowanych plików instalacyjnych, warto dołączyć pliki do VCS wraz z kodem testowym.

Chociaż pliki użyte w teście nie są kodem, można je wyświetlić jako zależność, na której opiera się kod. Dlatego warto trzymać wszystko razem.

Kontrapunktem jest to, że niektóre VCS nie radzą sobie dobrze z dużymi plikami binarnymi, a inne mają silny sprzeciw wobec umieszczania jakiegokolwiek pliku binarnego w VCS. Jeśli któryś z tych przypadków dotyczy Ciebie, sensowne byłoby również przechowywanie plików testowych w dobrze znanej lokalizacji, do której można łatwo uzyskać dostęp.

Zastanowiłbym się również nad umieszczeniem komentarza w kodzie testowym, który mówi: „polega na foo.pdfprzeprowadzeniu wszystkich testów”.

Nie widzę nic złego w sprawdzaniu danych testowych, jeśli nie zostaną znalezione, to próba ich uzyskania (np. Z adresu URL) i niepowodzenie, jeśli żaden z nich nie działał. Poleganie na sieci jest złym pomysłem, ponieważ sprawia, że testy są wolniejsze i delikatniejsze; ale próba jest mniej delikatna niż nie, a automatyczne pobieranie (i buforowanie lokalne) odpowiednich danych jest szybsze niż ręczne czytanie dokumentów / komentarzy, pobieranie i umieszczanie ich na miejscu.

— Warbo

7

Jeśli są to dane statyczne, to tak, umieść je w kontroli wersji. Te pliki tak naprawdę się nie zmienią po zalogowaniu; zostaną one usunięte, jeśli ta funkcja nie będzie już potrzebna, lub zostaną dodane nowe pliki testowe. Tak czy inaczej, nie musisz się martwić, że słabe binarne różnice zajmują miejsce.

Jeśli generujesz dane testowe, np. losowo, należy automatycznie zapisać go, gdy test się nie powiedzie, ale w przeciwnym razie odrzuć. Wszelkie dane zapisane w ten sposób powinny zostać przekształcone w regularne testy regresji, aby te przypadki brzegowe były zdecydowanie testowane w przyszłości, zamiast polegać na losowaniu.

— Warbo
źródło

2

Jeśli generujesz dane testowe losowo, powinieneś naprawdę wyjść i kupić książkę o pisaniu odtwarzalnych automatycznych testów.

— Dawood mówi, że przywróć Monikę

5

@DavidWallace Mówisz, że całe pola, takie jak testowanie fuzzów, sprawdzanie właściwości i testowanie oprogramowania statystycznego, są nie tylko złe, ale szkodliwe?

— Warbo

5

@DavidWallace random! = Nieodtwarzalny.

— congusbongus

5

@DavidWallace możesz nazwać to, jak chcesz. Losowe dane testowe, zapisywanie danych wejściowych, w razie potrzeby recykling, ergo powtarzalne. Nie prowadzi do świata bólu.

— congusbongus

2

@DavidWallace ”zamiast zastanawiać się, które przypadki testowe są rzeczywiście potrzebne” nie oznacza „bez losowych testów”, oznacza „nie tylko losowe testy”. Jeśli chodzi o „nie można odtworzyć danych, które znalazły błąd”, czy rzeczywiście przeczytałeś odpowiedź, na którą komentujesz? ;)

— Warbo

0

Zdecydowanie dołącz te dane do swoich testów i głównego kodu aplikacji. Pomaga mieć naprawdę dobrze zorganizowany zestaw testów - więc jeśli testujesz ekstrakcję pdf (i masz ten kod ładnie zamknięty), powinieneś być w stanie zbudować ścieżkę do danych testowych, na podstawie ścieżki do kodu aplikacji - to zawsze działało dla mnie.

Za pomocą git możesz skonfigurować .gitignore, aby uniemożliwić tymczasowe wyjście lub rejestrowanie testów przed zanieczyszczeniem twojego repozytorium.

— NickJHoran
źródło