Где я должен хранить тестовые данные?

У меня есть меньшие модульные тесты, которые используют небольшие фрагменты из реальных наборов данных. Я также хотел бы проверить свою программу на полные наборы данных по множеству причин. Единственная проблема заключается в том, что один реальный набор данных составляет около 5 ГБ. Я не нашел точных цифр для того, что могут хранить репозитории Git, но это кажется слишком большим.

Согласно этому посту программистов, я должен хранить все свои данные, необходимые для тестирования проекта в репозитории.

Решение, принятое моей командой, состоит в том, что у проекта есть файл, содержащий путь к подключенной к сети файловой системе, в которой хранятся наши тестовые данные. Файл Git игнорируется.

Я чувствую, что это несовершенное решение по двум причинам. Когда NAS не работает, работает медленно или не работает, мы не можем выполнить полный тест. Вторая причина заключается в том, что когда кто-то сначала клонирует репозиторий, модульные тесты не пройдены, поэтому им нужно выяснить, как монтировать объекты с определенным именем и синтаксисом, используемым для создания файла пути тестирования.

Так что мой вопрос в два раза. Сколько данных - это слишком много данных для хранения в системе контроля версий?

Как лучше обрабатывать большие объемы тестовых данных?

Как работать с большими файлами в цепочке сборки

Мне нравится использовать инструмент сборки, который управляет зависимостями - например, maven или gradle. Файлы хранятся в веб-хранилище, и инструмент автоматически загружает и кэширует их, когда обнаруживает зависимость. Это также устраняет дополнительную настройку (конфигурацию NAS) для людей, которые хотят запустить тест. И это делает обновление данных довольно безболезненным (это версия).

Что слишком велико, чтобы положить в контроль версий

Есть большая серая зона. И если вы решите, что что-то не входит в RCS, каковы ваши альтернативы? Это более простое решение, если вы ограничиваете свой выбор между RCS и бинарным репо (стиль maven).

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

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

Когда NAS не работает, работает медленно или не работает, мы не можем выполнить полный тест.

Очевидно, что это может быть решено только путем копирования 5 ГБ с NAS на локальный диск. Но нет необходимости делать это вручную.

Вторая причина заключается в том, что когда кто-то сначала клонирует репозиторий, модульные тесты не пройдены, поэтому им нужно выяснить, как монтировать объекты с определенным именем и синтаксисом, используемым для создания файла пути тестирования.

Вы можете предоставить простой сценарий оболочки, который выполняет именно это: подключите NAS с определенным именем и скопируйте данные на локальный диск, когда его там еще нет, или когда набор данных на NAS новее, чем локальный набор данных. Убедитесь, что скрипт будет запускаться автоматически на этапе инициализации ваших модульных тестов.

Конечно, когда существует не только один из этих наборов данных, но и целая куча зависимостей от внешних файлов вне вашего репозитория исходного кода, тогда лучше подойдет инструмент, подобный упомянутому в @ptyx.

... когда кто-то сначала клонирует репозиторий, модульные тесты не пройдены, поэтому им нужно выяснить, как монтировать объекты с определенным именем и синтаксисом, который использовался для создания файла пути тестирования.

Во-первых, просто иметь согласованную терминологию: этот вид теста (большие внешние зависимости, реальные данные) обычно считается не модульным, а скорее интеграционным или системным тестом .

С практической точки зрения: я считаю хорошей практикой разделять юнит-тесты и интеграционные тесты , потому что они имеют свои сильные и слабые стороны.

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

Таким образом, локальные сборки бывают быстрыми и надежными (практически без внешних зависимостей), а интеграционные тесты выполняются мощным CI-сервером. Это позволяет избежать проблемы, которую вы описываете.

Что касается того, как сохранить данные:

Один хороший вариант - это управление артефактами, подобное описанному в ptyx. Другой вариант - поместить тестовые данные в отдельный репозиторий . В любом случае данные не выпускаются вместе с основной сборкой, и наличие отдельного репо позволяет избежать принуждения всех к получению тестовых данных вместе с исходным кодом. Другими словами, используйте второй репо в качестве управления artifacdt :-).