Без лишних проволочек, предположим, что вы попали в следующую ситуацию:
у вас есть некоторый .NET проект;
для этого проекта вы написали NUnit-тесты (либо они уже написаны);
вам торжественно вручили Visual Studio 2008 Team System (или выше) или Visual Studio 2010 Premium (или выше) и поручили провести анализ покрытия кода тестами (aka code coverage).
Путь вам преграждает только одно маленькое "но": Test Runner, интегрированный в Visual Studio, видит только собственные MSTest'ы, а вашему любимому NUnit'у уделяет ноль внимания и преподносит фунт презрения. Что делать?
Вышеописанную ситуацию рассмотрим для простоты на маленьком примере. Создадим в Visual Studio (в нашем случае это Visual Studio 2010 Ultimate) новый проект типа Class Library и назовем его для пущей очевидности TestedAssembly. В вышеозначенный проект добавим один единственный класс TestedClass, который будет у нас состоять из единственного простейшего метода GetSomeString.
Теперь займемся проектом с тестами. Добавим в солюшен еще одну Class Library, которую назовем TestAssembly. В этой сборке у нас также будет всего один класс TestedClassTest c единственным методом GetSomeStringTest.
Ну а теперь настало время обсудить самое интересное: как заставить
Visual Studio собирать данные о покрытии кода по тестам, запускать которые она не хочет. Ну, раз не хочет, то и не будет, пусть этим делом займется профессионал своего дела, а именно сам NUnit. Добавим в наш многострадальный солюшен еще один проект, на этот раз типа Test Project, и назовем его, скажем, NUnitProxy. Студия автоматически положит в него файл UnitTest1.cs, который мы с чистой совестью удалим, а вместо него добавим Generic Test. В первом поле настроек теста нам нужно указать полный путь к nunit-console-x86.exe (обратите внимание, именно x86 - это важно), а во втором поле мы пропишем полный путь к сборке с тестами (в нашем случае это проект TestAssembly). Главное - не забудьте кавычки.
Теперь пройдем в папку Solution Items, которая магическим образом материализовалась в солюшене после добавления проекта NUnitProxy, и осуществим даблклик на файле Local.testsettings.
Откроется диалог Test Settings, в котором нам необходимо проследовать во вкладку Data and Diagnostics, отметить галочкой пункт Code Coverage и нажать кнопку Configure. Вашему взору предстанет окно Code Coverage Detail, предназначенное для выбора сборок, для которых Visual Studio будет собирать данные о покрытии кода. Здесь есть еще один маленький нюанс: если вы веберете сборку, которая лежит в папке \bin\Debug\ тестируемого проекта, то результатом анализа у вас будет чарующая пустота вселенной. Нажмите кнопку Add Assembly… и укажите путь к тестируемой сборке, которая лежит в папке \bin\Debug\ проекта с тестами (в нашем случае TestAssembly). Убедитесь, что выставлена галочка Instrument assemblies in place, и со спокойно душой жмите OK, Apply и Close.
Вот и все. Visual Studio видит наш proxy-тест, запускаем его, наблюдаем открывшуюся консоль NUnit и по завершению прогонки тестов направляемся во вкладку Code Coverage, где наблюдаем вполне выразительные результаты.
Ну и на последок две ложки дегтя в бочку меда. Во-первых, Visual Studio не умеет инструментировать x64 сборки со всеми отсюда вытекающими: хотите Code Coverage - перекомпилируйте под x86 (Any CPU тоже работает). Во-вторых, если код в сборке не покрыт вообще, то оная сборка не будет включена в итоговый отчет (можете поэкспериментировать, закоментировав тело метода GetSomeStringTest), что, как вы понимаете, в определенных ситуациях может привести к неправильному значению итогового покрытия (когда собираются данные для нескольких сборок).
