We started investigating adding support for running tests with Visual Studio’s built-in test runner. It would require Visual Studio 2008 SP1, and would require Professional edition or higher.
In order to support running xUnit.net tests in Visual Studio, we discovered that the project needs to be marked as one of Visual Studio’s Test projects (essentially, it’s a C#/VB.NET project that has extra bits inside it that tell Visual Studio the project contains tests). Projects which are marked this way cannot be opened in versions of Visual Studio that do not have unit testing support installed (this includes Standard and Express editions, which do not offer unit testing, as well as any user who opts not to install the unit testing support).
Practically speaking, this causes the following to be true:
- You must have a separate project for tests. You cannot place your tests inside your main project.
- If you have an existing project with tests in it, you need to edit the .csproj file to add the extra bits into it. (You can also start over with a new project and port the code, but hand editing the .csproj seems easier and more success-prone.)
- If you create a new Unit Test project, you will need to remember to remove any references to the Visual Studio Test DLLs, since these will not be present unless Visual Studio is installed (for example, on your continuous integration server).
- If you forget to change the project type, the support simply won’t work. There will not be any feedback as to why; the tests simply won’t show up in Visual Studios Test views.
- If your project is consumed by many users with various versions of Visual Studio (for example, if you’re running an open source project), you are more likely to run into the version limitations than if you’re using xUnit.net for an internal project with a consistent developer platform.
Given this context, if you have an opinion about how to proceed could you voice your opinion here.