« Ridiculous Legalese | Main | The CodePlex Team and the patterns & practices Summit »

September 20, 2007


Feed You can follow this conversation by subscribing to the comment feed for this post.


I don't think people are getting the fact that this bullet point:

* Single Object Instance per Test Method

Negates the need for Setup and TearDown. How do you setup and tear down a normal CLR object? Constructor and Dispose method (assuming IDisposable).

Mike Gale

What happens with existing projects that include large numbers of tests? When it comes time to enhance the project, I think most development teams will stick with the existing tests. The development time that goes into these tests is likely a big part of the effort spent.

Backward compatibility seems like a really good idea to help transition. Else we are creating "legacy tests".

I know that tests can be more important than the "conventional code base".


Nothing says both NUnit and xUnit can't both be used per solution, right?

Brad Wilson

That is correct, yup. You can have both NUnit and xUnit.net tests in the same assembly.

You can either "run" the assembly twice, one with each runner, or you can add "[RunWithNUnit]" to your NUnit fixtures so that the xUnit.net runner will actually run your NUnit tests. The [RunWithNUnit] attribute comes from xunit.extensions.dll.

Steve Freeman

Interesting proposal and nice to see the shared instance stuff go.

Have you also looked at jUnit4's adoption of Hamcrest (a matcher library) for implementing assertions? It's working pretty well for us and allows people to write custom assertions. I believe Charlie Poole included something equivalent in NUnit.


Brad Wilson

Steve, I've looked at the BDD style assertions in the past, and I can see there is value for both camps. We didn't provide that style of assertion, primarily for simplicity reasons. Speaking for myself here (and not Jim), I'm not a huge fan of giving people multiple ways to do something, because it really just confuses the issue of "which one is better".

Writing BDD style assertions that work with xUnit.net should be relatively trivial (after all, test frameworks are really just about throwing exceptions when things go wrong). It would be interesting to see if the community would be willing to contribute a "standard" extension to xUnit.net for BDD style assertions. For that matter, such a library should work with any of the .NET unit testing frameworks.

I feel the same way about mock object frameworks, personally. It doesn't have to be part of the unit testing framework; one should be able to pick and choose the pieces they want (NMock with NUnit, Rhino Mocks with xUnit.net, etc.) without feeling like one choice locks you into another.

jm2c :)

Yves Hanoulle

>But how about in the next version, a .NET plugin which can be >launched from a button click.
you can already do this with all console or gui testers:
you can confiure your visual studio to run any application when you run a project. (right click project/ select properties/ ...)


yeah. I don't think gui runner is necessary. Console runner is good enough.

Kevin Dente

The removal of the TestFixture attribute is a drag for those of us who like to keep their test fixture classes in the same assembly as the classes under test. Seems like it would make finding all the test methods much slower.

James Newkirk


With regard to speed, are you concerned about the runners ability to find the tests or for the people looking through the code?


The comments to this entry are closed.