<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="http://bloggingabout.net/utility/FeedStylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Search results matching tags 'Visual Studio' and 'NUnit'</title><link>http://bloggingabout.net/search/SearchResults.aspx?a=1&amp;o=DateDescending&amp;tag=Visual+Studio,NUnit&amp;orTags=0</link><description>Search results matching tags 'Visual Studio' and 'NUnit'</description><dc:language>en-US</dc:language><generator>CommunityServer 2008.5 SP2 (Build: 40407.4157)</generator><item><title>NUnitForVS: integrating NUnit tests into Visual Studio</title><link>http://bloggingabout.net/blogs/vagif/archive/2010/03/06/nunitforvs-integrating-nunit-tests-into-visual-studio.aspx</link><pubDate>Sat, 06 Mar 2010 20:23:45 GMT</pubDate><guid isPermaLink="false">813b6dfd-644e-4573-a816-eebab56ba0d0:482927</guid><dc:creator>VagifAbilov</dc:creator><description>&lt;p&gt;Roy Osherove &lt;a href="http://weblogs.asp.net/rosherove/archive/2010/03/05/nunit-vs-mstest-nunit-wins-for-unit-testing.aspx" target="_blank"&gt;listed advantages&lt;/a&gt; of NUnit over MsTest but also mentioned one MsTest’s strength that can be crucial for many developers: “the integration with other team system tools and reporting is just beyond compare and the reporting alone helps alot to find recurring breaking tests, code churn vs. new tests and others”. This reminded me about what I recently read in a book by Jeff McWherter and Ben Hall &lt;a href="http://www.testingaspnet.com/" target="_blank"&gt;Testing ASP.NET Web Applications&lt;/a&gt; where they said that forthcoming release of Visual Studio 2010 will make it possible to configure VS test runner to execute tests that use syntax different from MsTest.&lt;/p&gt;  &lt;p&gt;I am a faithful user of &lt;a href="http://www.testdriven.net/" target="_blank"&gt;TestDriven.Net&lt;/a&gt;, but I know that ability to use built-in Visual Studio test runner is an important factor that may affect the choice of unit test framework. So it would be nice to separate these decisions: selection of a unit test framework and selection of a test runner. I &lt;a href="http://social.msdn.microsoft.com/Forums/en-SG/vstsprerelease/thread/92da13df-0c4f-4212-be3b-cf1a9795a6ac" target="_blank"&gt;asked in Microsoft’s VS 2010 forum&lt;/a&gt; it new version of Visual Studio is really that flexible when it comes to configuring it’s test runner. Unfortunately not. Microsoft’s Euan Garden answered: “this was something we wanted to do in the release but never made it into the product.” However, Euan gave a couple of hints: Gallio and NUnit integration CodePlex project.&lt;/p&gt;  &lt;p&gt;I checked CodePlex and found &lt;a href="http://nunitforvs.codeplex.com/" target="_blank"&gt;NUnitForVS&lt;/a&gt;: NUnit integration for Visual Studio 2008. I downloaded an ran the installer and within 5 minutes was able to make Visual Studio development environment to treat NUnit tests as they were native MsTest. The only preparation (in addition to installing NUnitForVS) was to open test project file in a text editor and add the following entry to the first PropertyGroup:&lt;/p&gt;  &lt;p&gt;&amp;lt;ProjectTypeGuids&amp;gt;{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}&amp;lt;/ProjectTypeGuids&amp;gt;&lt;/p&gt;  &lt;p&gt;This has to be done to &lt;em&gt;every&lt;/em&gt; test project that uses NUnit, but otherwise Visual Studio won’t be able to classify the project as a test project (why should it? – the only type of test projects that it natively recognizes is MsTest). After this change Visual Studio accepts NUnit tests, and you will see all your tests in the Test View window:&lt;/p&gt;  &lt;p&gt;&lt;a href="http://bloggingabout.net/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/vagif.metablogapi/5270.NUnitForVS1_5F00_0D2E65EA.png"&gt;&lt;img title="NUnitForVS1" style="border-right:0px;border-top:0px;display:inline;border-left:0px;border-bottom:0px;" height="251" alt="NUnitForVS1" src="http://bloggingabout.net/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/vagif.metablogapi/0027.NUnitForVS1_5F00_thumb_5F00_2EAD9579.png" width="299" border="0" /&gt;&lt;/a&gt; &lt;/p&gt;  &lt;p&gt;So far so good. Next checkpoint is to run and debug some of these tests. This also works well and test results are displayed in a respective window:&lt;/p&gt;  &lt;p&gt;&lt;a href="http://bloggingabout.net/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/vagif.metablogapi/2425.NUnitForVS2_5F00_0A1C07F5.png"&gt;&lt;img title="NUnitForVS2" style="border-top-width:0px;display:inline;border-left-width:0px;border-bottom-width:0px;border-right-width:0px;" height="254" alt="NUnitForVS2" src="http://bloggingabout.net/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/vagif.metablogapi/6254.NUnitForVS2_5F00_thumb_5F00_17821AFB.png" width="594" border="0" /&gt;&lt;/a&gt; &lt;/p&gt;  &lt;p&gt;Note the very last test in this list, the one that is called “Add(2,3,5)”. This is a parameterized test implemented using TestCase attribute:&lt;/p&gt;  &lt;pre class="brush: csharp;"&gt;[TestCase(2, 3, 5)]
public void Add(int x, int y, int sum)
{
    Calculator calc = new Calculator();
    decimal result = calc.Add(x, y);
    Assert.AreEqual(sum, result, &amp;quot;Incorrect result&amp;quot;);
}&lt;/pre&gt;

&lt;p&gt;So using NUnitForVS we can exploit features of NUnit 2.5 that don’t exist in MsTest, and still Visual Studio correctly treats them. This is good news.&lt;/p&gt;

&lt;p&gt;When it comes to collecting code coverage, the situation is a little trickier. When I open code coverage window, I see not very encouraging message “Code Coverage is not enabled for this test run”:&lt;/p&gt;

&lt;p&gt;&lt;a href="http://bloggingabout.net/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/vagif.metablogapi/3146.NUnitForVS3_5F00_2790E9B2.png"&gt;&lt;img title="NUnitForVS3" style="border-right:0px;border-top:0px;display:inline;border-left:0px;border-bottom:0px;" height="129" alt="NUnitForVS3" src="http://bloggingabout.net/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/vagif.metablogapi/1234.NUnitForVS3_5F00_thumb_5F00_0709AA00.png" width="398" border="0" /&gt;&lt;/a&gt; &lt;/p&gt;

&lt;p&gt;Actually this is correct message: you have to explicitly enable code coverage instrumentation. But how? Apparently our solution sill lacks some piece, but luckily it’s easy to fix. All we need is to add a test configuration file with extension “testrunconfig”. Then we can activate its configuration and enable code coverage collection. One simple way to add such file is to add and then delete a test project to a solution (a “real” MsTest project). The MsTest project will be gone but will a trace in a form of test configuration file:&lt;/p&gt;

&lt;p&gt;&lt;a href="http://bloggingabout.net/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/vagif.metablogapi/6303.NUnitForVS4_5F00_348AC9C3.png"&gt;&lt;img title="NUnitForVS4" style="border-right:0px;border-top:0px;display:inline;border-left:0px;border-bottom:0px;" height="292" alt="NUnitForVS4" src="http://bloggingabout.net/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/vagif.metablogapi/3348.NUnitForVS4_5F00_thumb_5F00_49101941.png" width="328" border="0" /&gt;&lt;/a&gt; &lt;/p&gt;

&lt;p&gt;If you now enable code coverage instrumentation for assemblies in your solution and rerun the tests, you will see the coverate summary:&lt;/p&gt;

&lt;p&gt;&lt;a href="http://bloggingabout.net/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/vagif.metablogapi/3482.NUnitForVS5_5F00_1D5F4F45.png"&gt;&lt;img title="NUnitForVS5" style="border-right:0px;border-top:0px;display:inline;border-left:0px;border-bottom:0px;" height="242" alt="NUnitForVS5" src="http://bloggingabout.net/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/vagif.metablogapi/5556.NUnitForVS5_5F00_thumb_5F00_3FB6E4BE.png" width="813" border="0" /&gt;&lt;/a&gt; &lt;/p&gt;

&lt;p&gt;Pretty useless, isn’t it? The summary displays coverage only for the test assembly and not for the actual code under test. Why?&lt;/p&gt;

&lt;p&gt;More googling, and the explanation came from Peter Stephen’s blog post: even though coverage instrumentation is enabled for all assemblies in our solution, one of assemblies was taken from a wrong place: the assembly under the test lies both in its own “bin” folder and in the “bin” folder of the test assembly, and it is there it has to be taken from. To resolve the problem you just need to add the assembly from a right place:&lt;/p&gt;

&lt;p&gt;&lt;a href="http://bloggingabout.net/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/vagif.metablogapi/5305.NUnitForVS6_5F00_28F79D35.png"&gt;&lt;img title="NUnitForVS6" style="border-right:0px;border-top:0px;display:inline;border-left:0px;border-bottom:0px;" height="471" alt="NUnitForVS6" src="http://bloggingabout.net/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/vagif.metablogapi/8877.NUnitForVS6_5F00_thumb_5F00_288B6A40.png" width="642" border="0" /&gt;&lt;/a&gt; &lt;/p&gt;

&lt;p&gt;Note 2 copies of UnitTestDemo.dll. The unchecked one is the one that was added initially, the checked one was added manually. And everything works:&lt;/p&gt;

&lt;p&gt;&lt;a href="http://bloggingabout.net/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/vagif.metablogapi/0317.NUnitForVS7_5F00_2AC7F2FC.png"&gt;&lt;img title="NUnitForVS7" style="border-right:0px;border-top:0px;display:inline;border-left:0px;border-bottom:0px;" height="717" alt="NUnitForVS7" src="http://bloggingabout.net/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/vagif.metablogapi/8686.NUnitForVS7_5F00_thumb_5F00_5129D647.png" width="817" border="0" /&gt;&lt;/a&gt; &lt;/p&gt;

&lt;p&gt;Of course, I only tried NUnitForVS on a very simple project. I plan to check it out with more complex code. But so far it looks quite promising opening Visual Studio test runner for NUnit - the most popular unit test framework.&lt;/p&gt;</description></item><item><title>When NUnit stops working on a build machine…</title><link>http://bloggingabout.net/blogs/vagif/archive/2009/12/10/when-nunit-stops-working-on-a-build-machine.aspx</link><pubDate>Thu, 10 Dec 2009 12:13:58 GMT</pubDate><guid isPermaLink="false">813b6dfd-644e-4573-a816-eebab56ba0d0:482574</guid><dc:creator>VagifAbilov</dc:creator><description>&lt;p&gt;… then it’s time to check the registry entries. Make sure you see something like this:&lt;/p&gt;  &lt;p&gt;&lt;a href="http://bloggingabout.net/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/vagif.metablogapi/3157.NUnitRegistry_5F00_1300746A.png"&gt;&lt;img title="NUnitRegistry" style="border-right:0px;border-top:0px;display:inline;border-left:0px;border-bottom:0px;" height="173" alt="NUnitRegistry" src="http://bloggingabout.net/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/vagif.metablogapi/2465.NUnitRegistry_5F00_thumb_5F00_7C412CE0.png" width="372" border="0" /&gt;&lt;/a&gt; &lt;/p&gt;  &lt;p&gt;In case the build runs in the context of a dedicated user, not the one who logs on to a build machine and install applications, then it is likely that the build user does not have correct setup for NUnit assemblies. You can of course import missing registry entries into that user registry part, but the best is just to create them for everyone under LOCAL_MACHINE folder using path &lt;span style="font-size:10pt;font-family:&amp;#39;Arial&amp;#39;,&amp;#39;sans-serif&amp;#39;;"&gt;\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727\AssemblyFolderEx.&lt;/span&gt;&lt;/p&gt;</description></item></channel></rss>