Further to Patrick's response ....
So, it sounds to me like you have been asked to put some "unit tests"
around a bunch of code that has been written; or you've written some
code and thought 'right, this needs testing'.
My advice would be to take a look at what it is you are trying to
achieve, and what it is that you want to test. I would say that this
"problem" has been tackled wrongly. By working in this manner, what
you will find is that your "unit tests" are only testing your
implementation, i.e.
public class MyClass { public string MyName { get;set;} }
public void NamePropertyTest()
{
// Arrange
var myClass = new MyClass();
const string expectedName = "Bill";
// Act
myClass.MyName = expectedName;
// Assert
Assert.AreEqual(expectedName, myClass.MyName, "NameProperty does not
return expected name");
}
What exactly is this test doing? ... it's pretty much testing the .Net
framework's implementation of a Property getter/setter -which we know
MUST work, otherwise the framework would be pretty shoddy and nobody's
code would work. So, this is pretty much a useless test (unless of
course you are working on the .net framework, in which case, I would
say that this should definitely be one of the tests around Property
syntax and usage!)
Let's imagine however that this test is one of your "unit tests" and
is run regularly as part of your test suite. All is fine and dandy and
you're thinking that you've done a great job because you've got
yourself 100% code coverage when you run nCover or whatever, and your
test always passes.
Later on in response to a user request something changes about the
implementation of MyName ... for example, it might check that a
surname is present and return a concatenated "full name" instead of
the thing that you set, for example:
private string _myName;
private string _familyName;
public string MyName
{
set
{
_myName = string.IsNullOrEmpty(_familyName)
? value
: string.Format("{0} {1}", value,
_familyName);
}
get { return _myName; }
}
Forget for the time being that this functionality is completely whacky
and is in itself WRONG WRONG WRONG, and imagine that it is a real
requirement; so you've coded it all up and you've run your test and
all is well that ends well, but when you run your entire test suite
you get the assertion failed message : "NameProperty does not return
expected name". This happens because some other test perhaps the test
for FamilyName { get;set; } has set a family name, and now MyName
actually returns "Bill Richards" and not "Bill"
So what do you do to get your test to pass? Well, you could *hack* it
and make sure you setup and teardown your MyClass before each test
(although I say *hack* here, you really ought to do this and it is not
really a hack, even though it is for this example!), or you could
write into your test some fancy footwork to get hold of the FamilyName
if it has already been set and check that the returned value from
MyName is equal to Bill FamilyName. But you will most likely fiind
that out in the "real world" qwhen the application is deployed you
will get some *unexpected behaviour* something which you cannot
reproduce in your test environment.
This is because you have tailored your test to the implementation of
your class, instead of testing the behaviour of your class ...
Lots more to write on this subject, but it's time for bed and I think
that maybe I'm rambling a bit, and maybe even I've gone a little "off
topic"; but in a nutshell what I think I'm trying to say is ...
Write your Test first, then write your code to pass your test, and you
will find that you are testing the behaviour/requirement rather than
the impementation.
--
You received this message because you are subscribed to the Google Groups
"Rhino.Mocks" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rhinomocks?hl=en.
