Jeremy <A@B.COMwrote:
I understand what a unit test is. No problem there.
What I'm wondering is what, specifically, do most of you more experienced
developers mean by "writing" a unit test.
Personally, I mean writing the code for a unit test, along with any
comments in/around the code which are required to understand what it's
meant to do.
Am I correct to believe that you are referring to some way you
*document* your tests? If yes, can you provide some example? Given
the huge amount of unit tests that go on with any non trivial
application dev project I'd like to think that there is some standard
template that you follow (home grown, as it may be). At least that's
what I'd like to come up with as I try to improve my programming
habits.
Well, there tend to be naming conventions, but that's about it. I tend
to name my test classes after the class they're testing, but with
"Test" at the end (FooTest testing Foo, for instance) and I tend to
have an instance variable called m_subject of the type I'm testing, but
there's no much beyond that.
Different people will tell you different things about whether to have
the unit tests in the same assembly, but not compiled in release mode,
or to have them in a different assembly. I'm a "different assembly"
guy, although that does make things harder as you can't test internal
members and can't make members available just for testing (other than
with .NET 2.0's "friend" capability).
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog:
http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too