Unit Testing, Agile Development, Leadership & .NET - By Roy Osherove
Jim Newkirk is blogging about the down side of setup and teardown methods in test classes, and why you
I have a lot of respect for Jim Newkirk but I was reading Roy Osheroves blog entry about the new XUnit
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<string> 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!
I was away on vacation this week and when ever I go away the week is eventful, I came back to the news
Update : There's a new Unit test framework called XUnit.NET. More info here. MbUnit is gaining some momentum
Pingback from Adam Goucher » Blog Archive » Introducing xUnit.NET
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.
In my new ongoing quest to read source code to be a better developer , I now present the sixth in an
Pingback from Scott Hanselman's Computer Zen - The Weekly Source Code 6
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.
"unit testing is a method of testing that verifies the individual units of source code are working properly. A unit is the smallest testable part of an application. In procedural programming a unit may be an individual program, function, procedure,..
Pros Cons nUnit