Де слід зберігати дані тесту?

У мене є менші одиничні тести, які використовують невеликі фрагменти з реальних наборів даних. Я також хотів би перевірити свою програму на повний набір даних з безлічі причин. Єдина проблема полягає в тому, що один реальний набір даних становить приблизно ~ 5 Гб. Я не знайшов жодних важких цифр для зберігання репозиторіїв Git, але це здається занадто великим.

Відповідно до цієї програми програмістів, я повинен зберігати всі свої дані, необхідні для тестування проекту в сховищі.

Моя команда вирішила, що проект має файл, який містить шлях до мережевої файлової системи, що містить наші тестові дані. Файл Git ігнорується.

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

Отже, моє запитання двократне. Скільки даних - це занадто багато даних для зберігання в контролі редагування?

Який кращий спосіб обробити велику кількість тестових даних?

Як обробляти великі файли в ланцюжку збирання

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

Що занадто велике, щоб поставити під контроль редагування

Є велика сіра зона. І якщо ви вирішили, що щось не належить до RCS, які ваші альтернативи? Це простіше рішення, якщо обмежити свій вибір між RCS та бінарним репо (стиль Maven).

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

Будьте готові йти на компроміс для зручності розробника.

Коли NAS не працює, працює повільно, або працює в режимі зниження, ми не можемо провести повний тест.

Очевидно, це можна вирішити лише скопіювавши 5 Гб з NAS на локальний накопичувач. Але немає необхідності робити це вручну.

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

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

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

... коли хтось вперше клонує репозиторій, тести модуля проваляться, тому вони повинні з'ясувати, як змонтувати речі з певним іменем та синтаксисом, який використовується для створення файлу шляху тестування.

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

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

• відокремте два типи тестів у коді (умовне іменування, окремий проект, ...)
• надають спосіб запустити лише один із двох наборів тестів
• виконувати тільки одиничні тести під час звичайних збірок
• запустити тести інтеграції на вимогу та на сервері CI (безперервної інтеграції)

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

Щодо збереження даних:

Хороший варіант - це таке управління артефактами, як опис відповіді ptyx. Іншим було б помістити тестові дані в окреме сховище . Дані не видаються разом з основною збіркою, а наявність окремого РЕПО дозволяє уникнути змушення всіх взяти тестові дані разом із вихідним кодом. Іншими словами, використовуйте друге репо як ваше управління artifacdt :-).