Где вы храните файлы тестовых данных?

Question

В некотором роде этот вопрос. Вы храните их в дереве исходных текстов? Вы держите их в системе контроля версий?

Я думаю, что если ваши тестовые примеры относятся к файлам, то эти файлы являются частью спецификации поведения системы, поэтому они связаны с текущей версией системы, поэтому их следует проверить в системе контроля версий. , Но я не думаю, что они должны быть проверены на месте, потому что они не должны быть, и они могут быть довольно большими. Поэтому я склоняюсь к параллельному дереву, так что если файлы кода проекта находятся в $ svn / Code / foo / bar / baz, соответствующие файлы тестовых данных находятся в $ svn / TestData / foo / bar / baz, и последний будет доступен напрямую с сервера с помощью некоторого общего вспомогательного класса тестовых данных (который может кэшировать файлы локально?), который может просто принимать относительные пути и выяснять, где их найти. Имеет ли это смысл?

Полагаю, есть связанный с этим вопрос о том, насколько широко мне следует использовать внешние файлы для тестирования в первую очередь. Я думаю, что они часто хороши для «приемочных» тестов более высокого уровня.

Answer 1

Мы подписываемся на школу мысли «все идет под контролем источника» (анальный ретентив даже не начинает описывать нас).

Это означает, что контрольные примеры (код и данные) для всех уровней тестирования, за которые мы несем ответственность (единица, система, интеграция, перевод ...), образы CD / DVD с программным обеспечением для разработки, образы ОС, виртуальные машины для тестирования среды, все документы, в основном все , что потребуется для объединения сред разработки / тестирования, если все компьютеры и программное обеспечение в команде должны быть украдены - за исключением аппаратного обеспечения, но это только потому, что у нас нет нашел способ проверить это еще: -).

Дисковое пространство намного дешевле, чем время, необходимое для повторного поиска всего, что нам нужно. И когда версия программного обеспечения выпущена в дикую природу, мы фактически проверяем все, что нужно для создания этой версии, записываем ее на несколько DVD и тестируем процесс на чистом оборудовании. Затем мы делаем несколько копий и распространяем их по четырем уголкам вселенной ... ой, простите, увлеклись.

Но мы делаем делаем все, что я сказал, хотя сборочные DVD распространяются по нескольким географически разнесенным местам (на планете, а не по всей вселенной).

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

Answer 2

Но я не думаю, что они должны быть проверены на месте, потому что они не должны быть

Почему бы и нет? Тесты являются неотъемлемой частью любой сложной программной системы. Если они не могут работать без своих данных, они становятся бесполезными.

Идея удаленного сбора тестовых данных по мере необходимости интригует, но затем вы становитесь зависимыми от подключения к вашему серверу Subversion, когда все, что вам нужно сделать, это запустить тесты. Я думаю, что это добавляет ненужную сложность тому, что должно быть простым делом; выполнение тестов никогда не должно быть узким местом в разработке.

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

Чтобы в явном виде ответить на ваш вопрос, мы храним наши тестовые файлы в / tests, чтобы у каждой ветви был свой набор рабочих и полезных тестов.

Answer 3

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

trunk/
  +- Source/
  +- TestSource/
  \- TestData/

Затем тесты ссылаются на ../TestData/myTestData.xml или все, что им нужно.

Answer 4

Я добавляю их в систему управления версиями таким образом

- Trunk
     - Source
     - Lib
     - Tests
         - DescriptiveTestName_1
         - DescriptiveTestName_2
- Branches
     - v0.9
         - Source
         - Lib
         - Tests

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