Чи слід перевіряти дані тесту на контроль версій?

Я пишу тестовий код для функції, яка обробляє PDF-файли. Основна ідея тестів полягає в тому, що я вказую їх на деякі PDF-файли, які я спеціально вибрав, вони обробляють їх, і я перевіряю, що результат - це те, що я очікую.

Моє запитання: де я повинен зберігати ці великі PDF-файли? Чи слід перевірити їх на контроль версій разом із кодом? Або покласти їх десь ще? Очевидно, тестовий код марний без PDF-файлів (або навіть з різними PDF-файлами), але все ж, якщо розмістити їх у нашому сховищі, почувається неправильним.

Ваша система управління версіями повинна містити все необхідне для створення, компіляції, тестування та упаковки програми для розповсюдження (наприклад, MSI, RPM). Я також заперечую, що конфігурації побудови та інші сценарії також повинні знаходитись у контролі версій.

Я повинен мати можливість перевірити проект і мати повне середовище для компіляції, складання та тестування.

Існує два підходи до перевірки тестових даних. Спочатку ви можете перевірити самі тестові дані (у цьому випадку PDF-файли). По-друге, ви можете перевірити вихідні дані, які можуть бути використані для генерації тестових даних (якщо вони застосовуються). Це може бути сценарій SQL, завантажений у порожню базу даних, що містить тестові дані, або, можливо, текстовий файл, який можна скласти у PDF або інший файл.

Інші можуть не погодитись з перевіркою все на контроль версій, але я виявив, що в моєму професійному досвіді дуже важливо забезпечити можливість відновлення цілого середовища з нуля.

Якщо тести марні без підготовлених файлів налаштування, то має сенс включити файли у свій VCS разом із тестовим кодом.

Хоча файли, які використовуються в тесті, не є кодовими, ви можете розглядати їх як залежність, на яку покладається код. Тож є заслуга в тому, щоб все тримати разом.

Як контрапункт, деякі VCS недостатньо добре обробляють великі бінарні файли, а інші сильно протистоять включенню будь-якого бінарного файлу у VCS. Якщо будь-який із цих випадків стосується вас, то зберігання тестових файлів у відомому місці, до якого легко отримати доступ, також має сенс.

Я також хотів би поставити коментар до тестового коду, який говорить, що "покладається на те foo.pdf, щоб запустити всі тести".

Якщо це статичні дані, то так, покладіть їх на контроль версій. Ці файли насправді не зміняться після їх реєстрації; вони або видаляться, якщо ця функція більше не потрібна, або нові тестові файли будуть додані поряд. Так чи інакше, вам не потрібно турбуватися про погані бінарні відмінності, що займають місце.

Якщо ви генеруєте дані тесту, наприклад. випадково, тоді вам слід автоматично зберегти його, коли тест не вдасться, але відмовитися від нього інакше. Будь-які дані, збережені таким чином, повинні бути перетворені на регулярні регресійні тести, так що ці кращі випадки, безумовно, будуть перевірені в майбутньому, а не покладатися на удачу в розіграші.

Однозначно включайте ці дані разом із тестами та основним кодом програми. Це допомагає мати дуже добре організований тестовий набір - тому, якщо ви тестуєте вилучення PDF (і у вас цей код непогано інкапсульований), ви повинні мати можливість побудувати шлях до ваших тестових даних на основі шляху до коду програми - це завжди працювало для мене.

За допомогою git ви можете налаштувати .gitignore, щоб запобігти забрудненню вашого репо будь-якого тимчасового виводу або тестового журналу.