Я пишу тестовый код для функции, которая обрабатывает PDF-файлы. Основная идея тестов заключается в том, что я указываю на некоторые PDF-файлы, которые я выбрал специально, они обрабатывают их, и я проверяю, что результат соответствует ожидаемому.
Мой вопрос: где я должен хранить эти большие файлы PDF? Должен ли я проверить их в контроль версий вместе с кодом? Или положить их куда-нибудь еще? Очевидно, что тестовый код бесполезен без PDF-файлов (или даже с различными PDF-файлами), но, тем не менее, помещать их в наш репозиторий кажется неправильным.
testing
version-control
data
Swiftheart
источник
источник
Tests != Test DataОтветы:
Ваша система контроля версий должна содержать все, что нужно для сборки, компиляции, тестирования и упаковки приложения для распространения (например, MSI, RPM). Я также утверждаю, что конфигурации сборки и другие скрипты также должны быть в управлении версиями.
Я должен иметь возможность проверить проект и иметь полную среду компиляции, сборки и тестирования.
Существует два подхода к проверке данных испытаний. Во-первых, вы можете проверить сами данные теста (в данном случае PDF-файлы). Во-вторых, вы можете проверить исходные данные, которые можно использовать для генерации тестовых данных (если применимо). Это может быть сценарий SQL, загруженный в пустую базу данных с тестовыми данными, или текстовый файл, который можно скомпилировать в PDF или другой файл.
Другие могут не согласиться с проверкой всего в контроле версий, но я обнаружил, что по своему профессиональному опыту крайне важно обеспечить возможность полного восстановления среды с нуля.
источник
Если тесты бесполезны без подготовленных вами файлов установки, то имеет смысл включить файлы в VCS вместе с тестовым кодом.
Хотя файлы, используемые в тесте, не являются кодом, вы можете рассматривать их как зависимость, на которую опирается код. Так что есть смысл хранить все вместе.
В качестве контрапункта, некоторые VCS плохо обрабатывают большие двоичные файлы, а другие категорически против включения любого вида двоичных файлов в VCS. Если любой из этих случаев применим к вам, то также имеет смысл хранить тестовые файлы в хорошо известном месте, к которому легко получить доступ.
Я также хотел бы добавить комментарий к тестовому коду, который гласит, что «полагается на
foo.pdfвыполнение всех тестов».источник
Если это статические данные, тогда да, поместите их в систему контроля версий. Эти файлы действительно не изменятся, как только они будут зарегистрированы; они либо будут удалены, если эта функциональность больше не нужна, либо будут добавлены новые тестовые файлы. В любом случае вам не нужно беспокоиться о том, что плохие двоичные различия занимают место.
Если вы генерируете тестовые данные, например. случайно, тогда вы должны автоматически сохранить его, если тест не пройден, но в противном случае откажитесь от него. Любые данные, сохраненные таким образом, должны быть превращены в регулярные регрессионные тесты, чтобы эти крайние случаи были непременно проверены в будущем, а не полагаться на удачу розыгрыша.
источник
Обязательно включите эти данные в свои тесты и основной код приложения. Это помогает иметь действительно хорошо организованный набор тестов - поэтому, если вы тестируете извлечение PDF-файлов (и этот код хорошо инкапсулирован), то вы должны иметь возможность построить путь к своим тестовым данным на основе пути к коду приложения. - это всегда работало для меня.
С помощью git вы можете настроить .gitignore, чтобы предотвратить любой временный вывод или тестовую регистрацию от загрязнения вашего репо.
источник