I would agree with the Team System Stuff. Besides the points you mention, a unit testing framework should also be fast; team system is extremely slow (compared to NUnit, at least). I certainly plan on taking a look at mbUnit, though the truth is I'm a very happy NUnit user, overall.
I'm a recent MBUnit convert, I love the row test functionality - every time one of the users breaks a method I can add another attribute and hey presto that's tested for too.
I used NUnit a lot and found it too restrictive.
Kent: MbUnit doest *not* require any kind of DB to execute tests (nor does any other unit test framework except the ones that are DB-Specific like SQLUnit or DBUnit etc...
However, it can *support* using a db for some tests.
As for not using a DB as an external dependency - that's a long time argument.
Personally I believe that when you write a data access layer, you should purposly have integration tests rather than simple unit tests that check against the database, since the DB contains logic constructs such as constraints, sprocs, triggers etc..
more on this here:
http://weblogs.asp.net/rosherove/articles/dbunittesting.aspx
Roy.
I'm not sure why you worry about "frozeability" if the application does what you need to do and has an extensible framework. Unless you are doing some really crazy stuff, or the tool you are using has some serious bugs, what else do you need from it?
I guess what I'm saying is - if it does what you need to do now, it'll probably do at least the majority of what you need it to do for the forseeable future. And if its Open Source, you can always pick it up and add your own functionality to it yourself when your needs aren't being met.
It's not free for everyone to use ( you can't even use it with the VS express editions - shame on you!)
It's not supported in VS 2005 Pro either. Looks like you need a Team System install for it to be supported.
I've used NUnit until now, but after some of the buzz I've been hearing about MbUnit, I think I might have to give it a spin.
Cheers.
> I do tend to still use NUnit even with Team System - as I tend to get better features, more stability and a wider range of possibilities for running my unit tests that way.
Note that if you do this, none of your test metrics will go in the VSTS data warehouse.
Your list of "waaay too many bugs" in VSTS unit testing sounded a lot more like "Roy Osherove wants everything to work *exactly* like nUnit". Which is fine, but that's not exactly the same thing, now is it? ;)
Jeff: There's a difference between having features that work differently and having features that don't work at all (ExceptedException attribute does not actually assert on the expected test message, you can't have tests in an abstract test class and more).
And yes, I think that any unit testing system that claims to be a good solution shoudl at least have the same basic feature set of NUnit asserts and attributes.
Would you accept anything less?
Roy.
We were using NUnit for Unit testing. We got the copy of Team system with VS2005, so we converted to Team system. But after using for 5 months we were so sick of it(Bugs, No seperate UI, Tied to VS, etc) that we changed all tests back to Nunit. Now its NUnit all the way.
hehe.
MbUnit is better than NUnit.
MbUnit supply lots of new features, such as data driven testing, set of test cases...
MbUnit will be the do-facto standard if it continue developing new & useful features.
And, Resharper of JetBrain will support MbUnit soon.