Без лишних проволочек, предположим, что вы попали в следующую ситуацию:

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

Code Coverage по мотивам NUnit тестов в Visual Studio