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.