My response to this is ....
> Ok, there something I don't like: it seems like I'm testing the
> List<T>.Contains() method ...
How does it seem like you are testing the List<T>.Contains() method? I
don't follow that, what I get from the test is that I am asserting
that the returned List<T> contains something which I expect to be in
there, perhaps the better assertions might have been,
Assert.IsFalse(result.Contains("A"));
Assert.IsFalse(result.Contains("E"));
Assert.IsFalse(result.Contains("I"));
because in reality they are two different test, one is Assert that
what I expect to be in the returned list is in it (saying nothing
about what is not in the list), and the other is Assert that what I
expect to not be in the list is not in it (saying nothing about what
is in the list). But neither says, check that the List<T>.Contains
method works.
> ... In fact using this approach (which is quite
> black-box oriented) I cannot verify that at a certain point and under
> some conditions the List<T>.Contains() method is called, even if I can
> verify the effect of that call. Now, as I'm quite new to advanced
> unit-testing I ask: is it just a problem of mine? ;-)
Why on earth would you want to verify that List<T>.Contains() is
called? Surely that is, as Patrick has pointed out, an implementation
detail. The moment you change your
storage mechanism, your unit tests are broken. Unit tests should not
test the details of your implementation, but rather the effects of
your implementation.
First and foremost, I think, your best bet is ALWAYS to write your
test FIRST. At this point you know NOTHING about your implementation,
and therefore you will not be drawn in to testing your implementation.
Take a look at Patrick's example, it says absolutely nothing about the
implementation detail, all his test knows about is
1. There is an IRepository instance from which lists/arrays of strings
are retrieved
2. The IReppository interface exposes the function GetNext10Items
which returns a string array
2. There is a Provider instance that has a reference to an
IRepository, which we are going to build using constructor injection.
3. The Provider interface exposes a property called BlackList which
accepts a string array and is used to filter any results returned by
the Provider
4. The Provider interface exposes the function GetItems which returns
the next 10 items from the repository except for those items contained
in BlackList
To me, this test perfectly illustrates how to test for the expected
behaviour, regardless of how the objects are implemented. It also
illustrates perfectly how to write a test prior to implementation,
since Patrick does not have your implementation (indeed he even
queries to see if you have a repository).
We know what we want to construct before we construct it, so we must
be also be able to determine how we will know if we have constructed
what we want to construct. Think about it before you write any code at
all "how will I know for sure that this piece of code does what I
intend it to do?", the answer is your unit test -I mean, the answer
you come up with, is exactly what you need to write in your unit test,
and then you will be certain that you are testing for the desired
result rather than dictating HOW the result is achieved, because as we
all know, that can change.
:o)
--
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.
