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

Ответ 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 - это кусок пирога.

Edit
Здесь, как вы можете "вызывать" 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>

Ответ 2

Это старый поток, но я боролся с одной и той же проблемой, и я понял, что вы действительно можете запустить 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) останавливается при первой ошибке, когда команда возвращает ненулевое значение. Поэтому, если какие-либо тесты модулей не работают, он не будет продолжать выполнять какие-либо тесты в последующих сборках. Это не здорово, но если все тесты пройдут, то все они будут выполняться.

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

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

Ответ 6

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

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

Ответ 7

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

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

Ответ 8

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

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

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