Должны ли тестовые данные быть проверены в системе контроля версий?

40

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

Мой вопрос: где я должен хранить эти большие файлы PDF? Должен ли я проверить их в контроль версий вместе с кодом? Или положить их куда-нибудь еще? Очевидно, что тестовый код бесполезен без PDF-файлов (или даже с различными PDF-файлами), но, тем не менее, помещать их в наш репозиторий кажется неправильным.

testing version-control data

— Swiftheart
источник

2

Возможный дубликат Должны ли модульные тесты храниться в хранилище?

— CVn

19

@ MichaelKjörling:Tests != Test Data

— Роберт Харви,

4

@RobertHarvey Верно, но если тестовые данные требуются для теста, я чувствую, что это должно считаться частью теста. Это также подход, использованный всеми тремя ответами, насколько я понимаю.

— CVn

84

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

Я должен иметь возможность проверить проект и иметь полную среду компиляции, сборки и тестирования.

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

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

20

Да. Абсолютно да. Это 2014 год, нет никаких оснований для использования контроля версий, который не обрабатывает двоичные файлы без проблем.

— Килиан Фот

4

Я согласен, но вы определенно хотите избежать ситуации, когда вы также проверяете ненужные вещи. Например, если тестовые данные включают в себя «выходную» папку, содержащую все PDF-файлы, сгенерированные тестами, вы можете не включать их в репозиторий. Но я согласен, что сами тесты должны быть частью репозитория, а также любых пакетов, необходимых для его запуска.

— Кеннет Гарза

1

@KennethGarza Это не сложно, правда. Как правило, любой оригинальный контент (исходный код, исходный код теста, тестовые данные, носители, [настоящая] документация, сторонние библиотеки, сценарии сборки, сценарии инструментов, сценарии преобразования и т. Д.) Должен быть включен, а все данные которые могут быть получены в разумные сроки из исходных данных не должно быть. Кроме того, учитывая, что это тестовые результаты, они, вероятно, имеют смысл только после запуска тестов самостоятельно, иначе вы не тестируете свою программу, вы тестируете способность программного обеспечения VCS сохранять целостность ваших файлов :)

— Thomas

1

@ MarnenLaibow-Koser: проект, над которым я работал, чтобы обнаружить электрический сбой в имплантированных электрокардиостимуляторах, имел набор тестов более 40 ГБ. Не существует VCS, где работа с этим не противна. Наличие двух репозиториев - это отдельная хлопот администрации, но иногда это может быть лучшим выбором.

— whatsisname

1

@ MarnenLaibow-Koser ты понял. Интеграционные тесты находятся в отдельном репозитории, и если пользователь хочет запустить его локально, управление зависимостями извлечет для него zip-файл и распакует его. Обычно серверу / ферме Continuous Integration поручено выполнить интеграционное тестирование, и оно будет предотвращать ветвление функции слияния до тех пор, пока тестирование интеграции не пройдет.

— user482745

15

Если тесты бесполезны без подготовленных вами файлов установки, то имеет смысл включить файлы в VCS вместе с тестовым кодом.

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

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

Я также хотел бы добавить комментарий к тестовому коду, который гласит, что «полагается на foo.pdfвыполнение всех тестов».

Я не вижу ничего плохого в том, чтобы тесты проверяли тестовые данные, если они не были найдены, то пытались получить их (например, из URL) и не работали, если ни один из них не работал. Полагаться на сеть - плохая идея, потому что она делает тесты медленнее и более хрупкими; но попытка менее хрупка, чем нет, и автоматическое получение (и локальное кэширование) нужных данных происходит быстрее, чем ручное чтение документов / комментариев, их получение и размещение на месте.

— Warbo

7

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

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

— Warbo
источник

2

Если вы генерируете тестовые данные случайным образом, тогда вам действительно стоит пойти и купить книгу о написании воспроизводимых автоматических тестов.

— Дауд говорит восстановить Монику

5

@DavidWallace Итак, вы говорите, что целые поля, такие как нечеткое тестирование, проверка свойств и статистическое тестирование программного обеспечения, не только неправильны, но и вредны?

— Warbo

5

@DavidWallace random! = Невоспроизводимый.

— congusbongus

5

@DavidWallace, тогда вы можете называть это как хотите. Данные случайных испытаний, запись входных данных, повторное использование в случае необходимости, эрго воспроизводимые. Не приводит к миру боли.

— congusbongus

2

@DavidWallace «вместо того, чтобы думать о том, какие тестовые примеры действительно необходимы», не означает «никакого случайного тестирования», это означает «не только случайное тестирование». Что касается «вы не можете воспроизвести данные, которые нашли ошибку», вы действительно прочитали ответ, который комментируете? ;)

— Warbo

0

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

С помощью git вы можете настроить .gitignore, чтобы предотвратить любой временный вывод или тестовую регистрацию от загрязнения вашего репо.

— NickJHoran
источник