Hey Roy, thanks for the comments. :) A common theme we were shooting for is simplicity. Here are some answers to your questions:
We did not forget Fail. We attempted to simplify a lot of things in the system. I personally believe that the need to use Fail() means there is probably a missing Assert, so rather than encouraging people to use Fail, I'd like to know what assert is actually missing.
I believe mocking frameworks are best left outside the unit testing framework. Everybody has their feelings on which they like best. Personally I usually hand-write stubs, but of all the ones I've used, I like Rhino best.
"Equals" is a static method on Object. We explicitly override it and mark it obsolete because its name is so close to "Equal", but it's not the same thing.
Generics can be implicitly instantiated. Assert.Equal("foo", "bar") works just fine, since the compiler knows that both are strings and automatically calls Assert.Equal on your behalf.
For a while, we did have BeforeEachTest() and AfterEachTest() as part of ITestFixture, but we felt that leveraging the language as much as possible made more sense. Since we create a new instance of the test object for each test run, you can use the constructor and IDisposable.Dispose() in place of SetUp and TearDown.
We're going to devote a separate article soon to the process of migrating from NUnit, including the usage of our [RunWithNUnit] sample attribute in xunit.extensions.dll.
Thanks again!
Why not just add to NUnit? One of the main things I miss from NUnit compared to MBUnit for example is the RowTest attribute... but I would rather make a slight compromise in my test style and call methods from within my test than embark on a new framework!
I did put some effort into a "one line unit test" type framework last year but in practice then I was just using 2 frameworks. Unless theres a huge need I think it better to stick to the mainstream... my 2 cents ;-)
I love the reduced syntax for xUnit.net. I definately feel that NUnit suffers from bloating tests with more syntax than is required. For example, I often do not require setting up or tearing down tests. If I do why do I need an attribute to do it, when the test framework can just use the constructor instead. Often I do not require most of the feature set that NUnit offers. NUnit is unnessasarily harder to learn than xUnit.net. Often I only want a simple test method. xUnit is a better testing framework to support.
I think from a user point of view, use the one suits best in the situation you are testing.
I would still wait for xUnit.NET to mature because when I need some help, I can find a lot of information about nUnit then on xUnit.