Как мне сообщить 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

Чтобы уточнить ответ 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 2

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

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

Answer 3

Это старый поток, но я боролся с той же проблемой, и я понял, что вы действительно можете просто запустить 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 4

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

Answer 5

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

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

Answer 6

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

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

Answer 7

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

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

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

Answer 8

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

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