Post a Comment On: the urban canuk, eh

Although I’ve always been a huge proponent of NUnit, I’m finding I’m using MS Test more frequently for the following reasons: My organization is a large Microsoft partner, so there’s often some preference for Microsoft tools in our projects. Support for open source tools is a concern for some organizations I work with.  Although Tests are not part of the production deliverables, some organizations are very risk adverse and reasonably do not want to tie themselves to products without support or guarantee of backward compatibility. Severe Resharper withdrawal.  After spending several years with Resharper tools, I’ve spent the last year with a barebones Visual Studio 2008 installation.  Without the tight integration between Visual Studio and NUnit, attaching and debugging a process isn’t involuntary. If the JetBrains guys are listening, hook me up. Reluctantly, I’ve started to use Visual Studio Test warts-n-all.  Out of the box, MS Test has two very handy keyboard shortcuts where you can either Run (CTRL+R, T) or Debug (CTRL+R, CTRL+T) the current test, fixture or solution, depending on where your mouse is currently focused.  Oddly enough, I’ve found myself in a position where I’ve manually created a Test project by adding the appropriate references, but none of the Visual Studio Test features work, including these handy short cuts.  Any attempt to run these tests using these shortcut produces an error: No tests were run because no tests were loaded or the selected tests are disabled. This error is produced because the Test Adapter is looking for a few meta attributes in the project that are added when you using the New Test Project template. To manually create a MS Test project, in Visual Studio: Create a new Class Library project Add a reference to: Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll Right-click your project and choose “Unload Project”.

[Image]
Right-click on your project and choose “Edit <ProjectName>”

[Image]
Add the following ProjectTypeGuids element to the first ProjectGroup element:

<PropertyGroup> <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration> <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform> <ProductVersion>9.0.30729</ProductVersion> <SchemaVersion>2.0</SchemaVersion> <ProjectGuid>{4D38A077-23EE-4E9F-876A-43C33433FFEB}</ProjectGuid> <OutputType>Library</OutputType> <AppDesignerFolder>Properties</AppDesignerFolder> <RootNamespace>Example.ManualTestProject</RootNamespace> <AssemblyName>Example.ManualTestProject</AssemblyName> <TargetFrameworkVersion>v3.5</TargetFrameworkVersion> <FileAlignment>512</FileAlignment> <ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids> </PropertyGroup> Right-click on the Project and choose "Reload <Project Name>" Once reloaded, the handy shortcuts work as expected. Note for the curious: Guid {FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}: refers to C# project Guid {3AC096D0-A1C2-E12C-1390-A8335801FDAB}: refers to the “Test Project Flavor” From my limited understanding of how Visual Studio Test package works, it scans the solution looking for projects that can contain tests.  Without the magic ProjectTypeGuid, the class library is excluded from this process. Happy coding.