MSTest + MSBuild + Множество тестовых проектов - PullRequest
Новая
       18

MSTest + MSBuild + Множество тестовых проектов

2 голосов
/ 13 июля 2010

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

В рамках процесса сборки все тестовые проекты объединяются, и mstest вызывается один раз: 

mstest /textcontainer:project1 /testcontainer:project2 ...

Это больше не является жизнеспособным решением, поскольку составленная команда теперь имеет длину около 12 000 символов, что превышает максимальную длину для одной команды.

У нас есть несколько вариантов:

  1. создание пользовательской задачи для разделения списка проектов в логическом месте и двойной вызов mstest.
  2. вызов mstest один раз для каждого тестового проекта.

Есть ли какие-либо преимущества / недостатки в любом из вариантов? Или, возможно, альтернативные решения? ПРИМЕЧАНИЕ. У меня нет возможности вносить изменения в архитектуру проекта, только сценарии сборки.

Ответы [ 2 ]

0 голосов
/ 21 сентября 2011

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

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

b) Если это невозможно, то в tfsbuild.proj у вас должен быть раздел с именем TEST ARGUMENTS. Вы можете добавить ItemGroup. Вот тот, который я использую в своем проекте: 

<ItemGroup>
<!-- If Normal build run UnitTests + Integration tests-->
<TestContainer Include="$(OutDir)\Rbi.Viper.Framework.Test.UnitTests.dll" />
<TestContainer Include="$(OutDir)\Rbi.Viper.Services.Test.UnitTests.dll" />
<TestContainer Include="$(OutDir)\Rbi.Viper.Controls.Test.UnitTests.dll" />
<TestContainer Include="$(OutDir)\Rbi.Viper.RestfulServicesMvc.Tests.dll" />

<TestContainer Include="$(OutDir)\Rbi.Viper.Framework.Test.IntegrationTests.dll" />
<TestContainer Include="$(OutDir)\Rbi.Viper.Services.Test.IntegrationTests.dll" />
 </ItemGroup>
0 голосов
/ 13 июля 2010

Предостережение: я не знаком с MSTest, но с автоматизацией сборки в целом.

Причины для запуска всех тестов с одного бегуна

  • Проще пройти / не выполнить сборку в одном месте.
  • Предотвращает накладные расходы при порождении тестового прогона несколько раз.
  • Инструментам отчетности могут потребоваться все результаты теста в одном месте (файле) дляодин отчет.

Причины для запуска каждого теста из собственного организатора теста

  • Упрощенная конфигурация для проекта теста.
  • Упростить / ускорить повторный запуск заданного набора тестов.
  • Для ускорения тестирования организаторы тестов могут быть распределены по нескольким серверам.

Пока вы можете объединять всерезультаты теста в единый отчет ИЛИ , который не имеет значения для вашей команды, я бы рекомендовал разбить их как можно более точно (до одного участника теста на проект, если это возможно).

Если вы приобрели весь MS Team FoundaНабор инструментов сервера и MS Test Manager, я думаю, он будет поддерживать широкий спектр вариантов тестирования;другие фреймворки, такие как Gallio, могут удовлетворить ваши потребности без особых затрат и накладных расходов.

Ссылки

...