• 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.

• Are you interested in this feature?
• If you’re interested in this feature, please stack rank it against the other large-to-implement feature requests outstanding for the project:
  • Creating a full-featured GUI runner (20 votes)
  • Support TeamCity for continuous integration (18 votes)
  • Tests with no asserts should yield a warning (17 votes)
  • Resharper support for categories (12 votes)
  • Support PEX (1 vote)

But one Question: Is there a way to enable Xunit to run with the VS Test runner without using VSMDI-files?

I have a team that is using Xunit and we are struggling to get the tests to work with an integrated Team Build. We primilary use MSTEST unit tests, is there an easy way to convert xunit tests to MStest tests?

Thanks,

@ianceicys: Just been down the road, look at my recent posts on StackOverflow - they should give good pointers. Re conversion, I did a pile of of removals of [TestClass], replaces of IsNull, IsEqual, IsNotEqual, Assert.Fail, TestMethod.  Then you need to replace any TestInitalize/Cleanups, but they are less common. One thing you'll probably run into is VSTT private accessors - I ended up generating ones with publicize.exe and checking the bins in as VS2008 Test References get ignored without it (trying to run without VS on the build agent).  Then I ended up having to install VS for now as to get test results into the TFS repoisitory you need to do a mstest/publish, which only works with VSTT and TFC installed on the agent box. (The projects still need to reference Microsoft.VisualStudio.QualityTools.UnitTests if you use a publicize.exe _Accessor assembly, but this gets onto an agent box with TeamBuild anyway IIRC)

Before you start this work, ask yourself what you're gaining in business value out of this exercise though (I gained more focused test development with less bad crutches leading one in bad directions.  I thought I was gaining the ability not to have to install VSTT on a build box. Right now, I'm happy I did it, but not aws happy as UI was exepcting to be.

So, what are you hoping to gain?

@ianceicys: And another thing.  You'll run into ExpectedException. I was able to transform 200 in a flash using a CodeRush template, and a CR optimise usings worked really well to clean up references.  Well worth assessing how many you have and how long its going to take you to convert them all to Assert.Throws

@BradWilson: Re the actual question:

VS integration is irrelevant for me as I use RedGreen or TD.NET - I'm trying to get away from MSTEST and MSTESTism.  I guess xUnit.net can make the world a better place by creating less friction for people with hard selling jobs to do, but Roy Osherove's IMHO largely misinformed post put me off for far longer.  But then I've never worked in an env rife with MSTESTism :D

GUI runner, I will prob never use (Yes I know its implemented), but the NUnit auto-reload and re-run feature is killer - to dock on another monitor.  Its easy to show to anyone that thinks they want an integrated runner.

TeamCity is done and was critical.

I'd like clean TeamBuild support though (PM me if you want to see scripts I ended up with and/or any other shortcircuiting of my last few days rantings here and on SO)

Other two, not qualified to comment

Not sure if I was sub'd to Roy at the time (think I unsub'd and resub'd for a bit back then) but I, and I assume others also scanned his post and took things on board to a degree, which certainly delayed me evaluating.  Had I seen the rebuttal in time (not sure why it didnt register - I'm sub'd to your blog for ages...) I'd have wasted less time with other frameworks.  Keep up the great work and continue to be strong on keeping the core lean.

Have you made any progress in the VS test runner integration?  We are looking into alternatives to the resharper test runner, especially if it is able to report on specific inlinedata test case failures.

Re the GUI runner - I'd favor supporting 2010 over 2008.  Between RedGreen, Resharper, TD.NET and xunit.runner.gui, the bases are covered for people to get work done at 90% capacity. (The fact that the built in runner's attitude is such that it and I dont see eye to eye might have something to do with that view though)

Re TFS integration - this is a very important feature, no matter how regularly people *actually* use it - it can be make or break in the adoption decision. (If TFS ever catches up with TC on intregration of test stuff, that'll become even more obvious to people)

Disclaimer:  I'm a neophyte with xUnit.net in particular and unit testing in general.

I've been comparing MSTest with xUnit.net ... I do not see direct integration of the xUnit.net 1.5 GUI in the vs2008 or vs201n IDEs as a useful benefit.

see http://bradwilson.typepad.com/blog/2009/09/xunitnet-15-shipped.html; ALT+TAB is generally more than adequate.

There's somewhat of a risk that tying the 1.5 GUI to present and future vs IDE implementations could be a crippling disadvantage to the xUnit.net GUI because Brad and Jim have demonstrated that they tend to move faster that the vs IDE team.

Although I'm relatively satisfied with the xUnit.net console runner, I do like the way the external 1.5 GUI runner works ...

         at the moment, there are THREE features that I'd like to see added to the external xUnit.net GUI runner:

(a) the ability to jump directly from the external xUnit.net GUI to a specific [Fact] method within the vs IDE;

(b) the ability to jump directly from the external xUnit.net GUI to the specific failing line of code in the [Fact] method within the vs IDE; and

(c) the ability to run one or ALL xUnit.net [Fact] methods in Debug mode, similar to the way that one initiates Test, Debug for MSTest methods.

     (c) is more necessary for tracing poorly written unit tests; well written unit tests should generally not require stepping through the unit test.

One major disadvantage of building xUnit.net into vs2008 and vs201n IDEs is that it
may leave behind those developers who are using the FREE Express versions of vs
and the lower cost Standard version of vs.

regards ~~ gerry (lowry)

@ Gerry

Just wanted to say that I think (c) is already possible. If you know that a test is failing you can go into VS (I'm using 2008 Professional) and debug it. Here are the steps:

1. Open the project properties for the project with the [Fact] you want to check in it.
2. Go to the Debug tab.
3. Under Start Action click the Start external program radio button and fill in the path to the console runner. (i.e. - {Path}\xunit.console.exe).
4. Under Start Options entered the path to the compiled assembly to test. (i.e. - {Path}\bin\Debug\TestProject.dll).
5. Save your changes.
6. Set the project as the Startup Project.
7. Set a breakpoint wherever if you want.
8. Start debugging.

This didn't work for me at first even after seeing people mention to start an external program because I'm in a multi project solution and a different project was the startup project.

That being said if you your (a) request was implemented this would be much easier. After setting the project up you could run the test in the GUI, go to the failing [Fact] from there, hit your breakpoint and start debugging. It's not something I feel much need of but it could be a time-saver. ^.^

@Gerry: Good to have another set of views on this.

For me, the xUnit GUI runner isnt natural to use as-is (my concerns are logged as issues).

But TD.NET just does all the above and more. I guess most people are using TD.NET and not even feeling any of this point which is why lots of people will press a vote button for it but much fewer will go in and explain their considered thoughts in full to the degree you have (i.e., the camp that really feel that pain have a solution already in TD.NET and arent waiting for xUnit.net to provide the answer).

Speaking for myself in regard to Team Build it is about the whole package vs. an individually item. We are doing TDD and would love to use xUnit but losing the stats that come out of the Team Build process drives us down the MSTest route.

The reason is that we are asked (rightly or wrongly) to provide stats to management teams and the sacrifices we have to make in using MSTest to be able to get stats out outweigh the issues that we have with it.

Is this a feature that is still being considered? Our organization is currently looking into unit testing options and free Visual Studio integration is something we are very interested in. I have personal experience with xUnit.NET and really like it, however if Visual Studio integration isn't feasible without the use of third-party tools, such as TestDrive.NET or Resharper, this may be a reason for us to adopt a different unit testing framework. If this is something that you plan on working on, would you be able to provide any time estimates for when we might see it in an xUnit build?

Thanks again for making a great and versatile testing framework!

It is the same in our organization. Like it or not, some people (usually key decision makers) view integration into the current tool-set a must have. I have been using xUnit.NET for a number of years now and am in love with its simplicity and how it encourages a better design for tests. However, I am facing the possibility of having to migrate all of my tests (numbering in the 1000s) over to MS Test simply due to the "appearance" of quality.

Wouldn't use VS integration personally as I have R# BUT, I think for the betterment of xUnit generally, it needs to be as integrated as possible. The wider the audience the greater level of exposure, acceptance and traction it will gain.

We all know the issues with the built in stuff from MS which is why a lot of us use other tools (among other reasons) but a huge number of developers are unable, unwilling or ignorant of the options therefor any other toolset has to do *at least* what the MS version does.

Integration is essential, even if a lot of us here won't be using it.

For my team and I, testing newbies running VS2010 Ultimate and using TFS, we'd really like to see a little more integration. ReSharper seems (again, newbies) to be a great test runner, but now we're looking at purchasing a code coverage tool such as dotCover (something we already paid for with our Ultimate licenses) and we still haven't figured out how to integrate our xUnit.net tests with TFS. (Yes, I've seen the posts and I know it should be possible, but TFS itself has quite a learning curve and I sure wouldn't mind if the little "run tests" checkbox just worked.) So if VS test runner integration is a precursor to working with the coverage, performance, and TFS integration we've already got then it would be at the top of our list, more so than anything else I've seen discussed here. ReSharper categories support would probably be second, but a distant second.

Hope the perspective from the small, very Microsoft, and new to unit testing crowd helps!

Thanks for the opportunity to give my input,

Drew Loika
University of Oregon

Any update on this from the xUnit team? Visual Studio integration will be a deciding factor for our organization on which testing framework we will use moving forward. Here's hoping that it makes it into a future release. :)

Thanks.

See the Support VSTS Test Runner work item for a VS2010 extension.  Be sure to read the entire comment for full details and caveats.