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.