Как сообщить MSTEST о запуске всех тестовых проектов в решении?

Question

Мне нужно знать, как сообщить MSTEST о запуске всех тестовых проектов в файле решения. Это нужно сделать из командной строки. Сейчас я должен передать ему конкретный файл проекта, я пытаюсь запустить его из файла SOLUTION.

Я надеюсь, что это возможно, потому что в Visual Studio нажатие Ctrl + R, A запускает ВСЕ тесты в открывшемся в настоящее время решении.

То, как я интерпретировал файлы справки, вам необходимо передать в каждой DLL специально.

Я хочу запустить это из командной строки с моего сервера CruiseControl.NET, поэтому я могу написать другие утилиты, чтобы это произошло. Если есть странный способ заставить это произойти с помощью какого-то ДРУГОГО метода, дайте мне знать.

Как сообщить MSTEST о запуске всех тестовых проектов для решения?

<exec> 
    <!--MSTEST seems to want me to specify the projects to test --> 
    <!--I should be able to tell it a SOLUTION to test!--> 
    <executable>mstest.exe</executable> 
    <baseDirectory>C:\projects\mysolution\</baseDirectory> 
    <buildArgs>/testcontainer:testproject1\bin\release\TestProject1.dll 
    /runconfig:localtestrun.Testrunconfig 
    /resultsfile:C:\Results\testproject1.results.trx</buildArgs> 
    <buildTimeoutSeconds>600</buildTimeoutSeconds> 
</exec> 

Answer 1

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

Если вы не добавляете тестовые проекты все время, вам очень редко придется его модифицировать.

Answer 2

Почему не просто msbuild выводит все тестовые сборки в папку.

Попробуйте установить параметры OutputPath, OutputDir, OutDir в msbuild для этого.

затем выполнить mstest для всех сборок в этой папке.

Answer 3

Вы можете применить какое-либо соглашение о наименовании и расположении тестовых проектов, тогда вы можете запустить MSTest, скажем, все * Test.dll ниже местоположения вашего решения.

Насколько я знаю, нет способа рассказать тестовый проект из «нормального» проекта на основе DLL на файле решения. Таким образом, альтернативой может быть анализ файлов проекта и/или .vsmdi файлов для поиска тестовых проектов, но это может быть довольно сложно.

Answer 4

Не знаю напрямую, но это может помочь VSMDI [fx: плюется в угол]. В своем решении добавьте все тесты в VSMDI. И затем передайте VSMDI для использования с помощью/testmetadata.

Однако я предлагаю вам следовать вышеприведенным соглашениям. И используйте соглашение об именах и дамп из файла SLN, используя, например, цикл for в командном скрипте.

Answer 5

Чтобы уточнить ответ VladV и сделать что-то более конкретным, в соответствии с предлагаемым соглашением об именах, выполняющим ваши тесты, может быть легко быть автоматизированным с MSBuild. Следующий фрагмент из файла msbuild моего текущего проекта делает именно то, что вы просили.

<Target Name="GetTestAssemblies"> 
    <CreateItem 
     Include="$(WorkingDir)\unittest\**\bin\$(Configuration)\**\*Test*.dll" 
     AdditionalMetadata="TestContainerPrefix=/testcontainer:"> 
     <Output 
      TaskParameter="Include" 
      ItemName="TestAssemblies"/> 
    </CreateItem> 
</Target> 
<!-- Unit Test --> 
<Target Name="Test" DependsOnTargets="GetTestAssemblies"> 
    <Message Text="Normal Test"/> 
<Exec 
    WorkingDirectory="$(WorkingDir)\unittest" 
    Command="MsTest.exe @(TestAssemblies->'%(TestContainerPrefix)%(FullPath)',' ') /noisolation /resultsfile:$(MSTestResultsFile)"/> 
    <Message Text="Normal Test Done"/> 
</Target> 

Кроме того, интеграция MsBuild с CruiseControl - это кусок пирога.

Редактировать
Вот как можно «назвать» MSBuild из вашего ccnet.config.

Во-первых, если вы еще не используете MSBuild для автоматизации сборки добавьте следующий XML вокруг фрагмента кода, представленного ранее:

<Project DefaultTargets="Build" 
    xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> 
    ..... <insert snippet here> ..... 
</Project> 

Сохранить в, например, RunTests.proj рядом с вашим решением в исходном дереве. Теперь вы можете изменить немного ccnet.config выше следующее:

<msbuild> 
    <executable>C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe</executable> 
    <workingDirectory>C:\projects\mysolution\</workingDirectory> 
    <baseDirectory>C:\projects\mysolution\</baseDirectory> 
    <projectFile>RunTests.proj</projectFile> 
    <targets>Test</targets> 
    <timeout>600</timeout> 
    <logger>C:\Program Files\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger> 
</msbuild> 

Answer 6

я знаю, эта нить довольно старый, но все еще высоко на Google, так что я думал, что я мог бы помочь один или два. В любом случае, поскольку для этого нет удовлетворительного решения. Я написал для этого задачу msbuild. подробную информацию можно найти здесь: http://imistaken.blogspot.com/2010/08/running-all-tests-in-solution.html

Answer 7

Это старая нить, но я боролся с той же проблемой, и я понял, что вы действительно можете просто запустить MSTest на каждой DLL в целом решение и оно не действительно вызывают проблемы. MSTest ищет методы в сборках, отмеченных атрибутом [TestMethod], а сборки, которые не являются «тестовыми» сборками, просто не будут иметь методов, украшенных этим атрибутом. Таким образом, вы получаете «Нет тестов для выполнения». сообщение назад и никакого вреда.

Так, например, в NAnt вы можете сделать это:

<target name="default"> 
    <foreach item="File" property="filename"> 
     <in> 
      <items> 
       <include name="**\bin\Release\*.dll" /> 
      </items> 
     </in> 
     <do> 
      <echo message="${filename}" /> 
      <exec program="C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\MSTest.exe"> 
       <arg value="/testcontainer: ${filename}" /> 
       <arg value="/nologo" /> 
      </exec> 
     </do> 
    </foreach> 
</target> 

и он будет работать все методы испытаний в каждой DLL в каждой папке Bin \ Release в растворе. Те, которые не являются тестовыми DLL, возвратят «Нет тестов для выполнения». и те, у которых есть тесты, проведут тесты. Единственная часть, которую я еще не выяснил, заключается в том, что выполнение (в NAnt) останавливается при первой ошибке, когда команда возвращает ненулевое значение. Поэтому, если какие-либо тесты модулей не работают, он не будет продолжать выполнять какие-либо тесты в последующих сборках. Это не здорово, но если все тесты пройдут, то все они будут работать.

Answer 8

Я только что решил эту проблему недавно. Вот мое предложение: Используйте testmetadata + testlist вариант MSTest

1. Сначала вы должны создать testlist в testmetadata файле (VSMDI)
2. командная строка должна быть mstest /testmetadata:....vsmdi /testlist:<name>
3. Затем используйте CCNET конфиг для запуска MSTest