Данная статья является переводом публикации из Sudhaka"s WebLog " Customizing Code Coverage in Visual Studio 11 ".
Инструмент Code Coverage в Visual Studio 11 по умолчанию анализирует все бинарные (exe / dll) файлы решения, которые загружаются во время выполнения модульного тестирования. Мы советуем вам придерживаться этого пути, поскольку это срабатывает практически во всех случаях.
Однако, могут возникнуть ситуации, когда вам понадобиться пере настроить такое поведение. Наиболее общим случаем может являться необходимость включения / исключения определенных двоичных файлов из покрытия кода. При выполнении таких действий может возникнуть ситуация, когда новые сборки, добавляемые в проект, могут выпасть из покрытия. Тем не менее, если такая необходимость все-таки возникнет, вы можете кастомизировать настройки покрытия кода. Другим распространенным случаем является необходимость настройки путей поиска символьных файлов для двоичных файлов, символьные данные которых не развернуты локально.
В данной статье мы обсудим настройку покрытия кода для подобных сценариев.
Файл .runsettings.
Расширенные настройки покрытия кода в VS11 содержатся в файле .runsettings. Данный файл является конфигурационным для инструментов тестирования в VS11.
Некоторые из вас, кто уже использовал VS 2010, знакомы с файлами .testsettings. Вы можете спросить: почему этот же файл не используется в VS11? Причина этого в том, что файлы .testsettings используются исключительно в модульных тестах MSTest в VS 2010. Модульное тестирование в VS11 использует не только MSTest, но и адаптеры тестирования от независимых разработчиков, например, NUnit и xUnit.net. Файл .testsettings с ними работать не будет. Поэтому был создан файл .runsettings.
Для настройки покрытия кода вам понадобится добавить файл .runsettings к вашему решению. В данный момент для этого не существует встроенного шаблона, выполняющего эту операцию. Добавьте этот файл как xml и отредактируйте эго содержимое:
- Щелкните правой на решении, затем Add New Item -> XML File, сохраните файл как CodeCoverage.runsettings (важно использовать именно это расширение).
- Скопируйте данные, которые будут приведены ниже, в этот файл.
- Отредактируйте настройки покрытия кода, как описано в следующей секции.
- Объявите эти настройки основными при помощи Test -> Test Settings -> Select Test Settings File.
После этого указанные настройки будут использоваться всякий раз, когда вы анализируете покрытие кода.
Основные сценарии настройки.
Настройка набора двоичных файлов для анализа на покрытие.
В этом разделе мы настроем подключение / исключение двоичных файлов из покрытия кода. При использовании файла .runsettings имеется два способа выполнения этой задачи.
Настройка исключением.
Этим способом можно включить все файлы, за исключением некоторых. Такой путь подходит, если код интересующих файлов часто меняется, и постоянно появляются новые бинарники: вам может потребоваться, чтобы новые файлы автоматически включались в покрытие. В то же время, у вас есть двоичные файлы, которые вы не хотели бы включать в покрытие, например, авто тесты. Они будут исключены.
Оставьте раздел <include> пустым, чтобы подключить все сборки. Укажите лишь имена и пути к тем сборкам, которые вы хотите исключить.
<ModulePaths>
<Include>
<!-- Do not specify any includes. This will attempt to include all binaries -->
</Include>
<Exclude>
<!-- Exclude modules that't to be processed, by their name / path -->
<ModulePath> .*MyCompany.MyTests1.dll</ModulePath>
<ModulePath> .*CPPUnitTestFramework.*</ModulePath>
</Exclude>
</ModulePaths>
Настройка включением.
Этот метод позволяет подключить лишь те файлы, что нам нужны, при этом исключив все остальные. Такой путь хорошо использовать, когда назначение двоичных файлов хорошо известно, и вы хотите подключить только эти файлы.
Перечислите подключаемые файлы. Раздел <exclude> оставьте пустым, чтобы исключить остальные.
<ModulePaths>
<Include>
<!-- Include modules of interest, by their name / path -->
<ModulePath> .*MyCompany.MyComponent.dll</ModulePath>
</Include>
<Exclude>
<!\uc1\u8212?- Do not specify any excludes. Anything not included will get excluded -->
</Exclude>
</ModulePaths>
Хотя разделы include и exclude могу использоваться одновременно, такое смешение может запутать. Поэтому старайтесь придерживаться одного из перечисленных механизмов настройки.
Указание путей поиска символьной информации.
Анализ покрытия кода требует наличия символьной информации (PDB) для исследуемых двоичных файлов. Для файлов, собранных вашим решением, символьная информация обычно представлена вместе с двоичной, и анализ покрытия будет работать автоматически. В некоторых случаях вы можете ссылаться на внешние, по отношению к вашему решению, двоичные файлы. В такой ситуации вам потребуется указать путь поиска символьной информации в файле rusettings.
<SymbolSearchPaths>
<Path> >\\\\mybuildshare\\builds\\ProjectX</Path>
</SymbolSearchPaths>
Здесь вы можете указывать пути как к локальным, так и удаленным папкам. Однако имейте в виду, что загрузка символьной информации может занимать продолжительное время, особенно, когда используется удаленный путь, содержащий большое количество двоичных файлов. Наилучшим выходом будет копирование символьных файлов вместе с бинарными, без указания пути поиска.
Пример файла .runsettings.
Ниже приведен пример файла runsettings. Используйте его при создании собственного файла настроек и вносите изменения по мере необходимости.
<?xml version= "1.0 " encoding= "utf-8 "?>
<RunSettings>
<DataCollectionRunSettings>
<DataCollectors>
<DataCollector friendlyName= "Code Coverage "
uri= "datacollector://Microsoft/CodeCoverage/2.0 "
assemblyQualifiedName= "Microsoft.VisualStudio.Coverage.DynamicCoverageDataCollector,
Microsoft.VisualStudio.TraceCollector, Version=11.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a ">
<Configuration>
<CodeCoverage>
<ModulePaths>
<!--
About include/exclude lists:
Empty "Include" clauses imply all; empty "Exclude" clauses imply none.
Each element in the list is a regular expression (ECMAScript syntax).
An item must first match at least one entry in the include list to be included.
Included items must then not match any entries in the exclude list to remain included.
It is considered an error to exclude all items from instrumentation as no data would be collected.
-->
<Include>
<ModulePath> .*\\\\UnitTestProject1\\.dll</ModulePath>
</Include>
<Exclude>
<ModulePath> .*CPPUnitTestFramework.*</ModulePath>
</Exclude>
</ModulePaths>
<UseVerifiableInstrumentation> True</UseVerifiableInstrumentation>
<AllowLowIntegrityProcesses> True</AllowLowIntegrityProcesses>
<CollectFromChildProcesses> True</CollectFromChildProcesses>
<CollectAspDotNet> False</CollectAspDotNet>
<!--
Additional paths to search for symbol files. Symbols must be found for modules to be instrumented.
If symbols are alongside the binaries, they are automatically picked up. Otherwise specify the here.
Note that searching for symbols increases code coverage runtime. So keep this small and local.
<SymbolSearchPaths>
<Path>C:\\Users\\User\\Documents\\Visual Studio 11\\Projects\\ProjectX\\bin\\Debug</Path>
<Path>\\\\mybuildshare\\builds\\ProjectX</Path>
</SymbolSearchPaths>
-->
<Functions>
<Exclude>
<Function> ^std::.*</Function>
<Function> ^ATL::.*</Function>
<Function> .*::__GetTestMethodInfo.*</Function>
<Function> ^Microsoft::VisualStudio::CppCodeCoverageFramework::.*</Function>
<Function> ^Microsoft::VisualStudio::CppUnitTestFramework::.*</Function>
<Function> .*::YOU_CAN_ONLY_DESIGNATE_ONE_.*</Function>
</Exclude>
</Functions>
<Attributes>
<Exclude>
<Attribute> ^System.Diagnostics.DebuggerHiddenAttribute$</Attribute>
<Attribute> ^System.Diagnostics.DebuggerNonUserCodeAttribute$</Attribute>
<Attribute> ^System.Runtime.CompilerServices.CompilerGeneratedAttribute$</Attribute>
<Attribute> ^System.CodeDom.Compiler.GeneratedCodeAttribute$</Attribute>
<Attribute> ^System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverageAttribute$</Attribute>
</Exclude>
</Attributes>
<Sources>
<Exclude>
<Source> .*\\\\atlmfc\\\\.*</Source>
<Source> .*\\\\vctools\\\\.*</Source>
<Source> .*\\\\public\\\\sdk\\\\.*</Source>
<Source> .*\\\\microsoft sdks\\\\.*</Source>
<Source> .*\\\\vc\\\\include\\\\.*</Source>
</Exclude>
</Sources>
<CompanyNames>
<Exclude>
<CompanyName> .*microsoft.*</CompanyName>
</Exclude>
</CompanyNames>
<PublicKeyTokens>
<Exclude>
<PublicKeyToken> ^B77A5C561934E089$</PublicKeyToken>
<PublicKeyToken> ^B03F5F7F11D50A3A$</PublicKeyToken>
<PublicKeyToken> ^31BF3856AD364E35$</PublicKeyToken>
<PublicKeyToken> ^89845DCD8080CC91$</PublicKeyToken>
<PublicKeyToken> ^71E9BCE111E9429C$</PublicKeyToken>
<PublicKeyToken> ^8F50407C4E9E73B6$</PublicKeyToken>
<PublicKeyToken> ^E361AF139669C375$</PublicKeyToken>
</Exclude>
</PublicKeyTokens>
</CodeCoverage>
</Configuration>
</DataCollector>
</DataCollectors>
</DataCollectionRunSettings>
</RunSettings>
Выбор файла runsettings во время выполнения модульного тестирования.
Модульные тесты могу запускаться в различном контексте. Ниже показано как указать нужный runsettings файл в конкретном случае.
При помощи Visual Studio IDE.
Выберите нужный файл при помощи Test -> Test Settings -> Select Test Settings File. Затем вызовите Analyze Code Coverage.
При помощи командной строки.
Запустить модульное тестирование из командной строки можно при помощи vstest.console.exe. Это - преемник MSTest. Он может запускать не только тесты MSTest, но и другие адаптеры, например, NUnit, xUnit, xUnit.net и др. Для запуска тестов используйте runsettings файл, как указано ниже:
- Запустите командную строку Visual Studio Native Tools.
- Выполните:
> vstest.console.exe TestAssembly.dll /EnableCodeCoverage /settings:CodeCoverage.runsettings
Во время сборки.
Модульное тестирование можно настроить на запуск в процессе сборки при помощи TFS Build Definition. Если у вас есть собственный файл runsettings, вы можете использовать его в процессе сборки. Ниже перечислены необходимые для этого действия:
- Отредактируйте описание процесса сборки. Откройте вкладку Process и измените настройки запуска тестов.
- Убедитесь, что будет использоваться Visual Studio Test Runner. Установите Options в Custom. Нажмите Browse для выбора файла с настройками.
- Укажите файл настроек и сохраните описание процесса сборки.
