> Just curious you see...
>
> I'm going to know up your tests and the command & validator classes
> without mocks, just to see what the difference is like...but give me a
> few hours as I'm about to go cook the dinner :)

Signature
Darryl L. Pierce <mcpierce@gmail.com>
Homepage: http://mcpierce.multiply.com/
"McVeigh's lawyer got him the death penalty, which, quite frankly,
I could have done." - Jon Stewart
>> Do you mock String, Integer, Boolean, Map, etc, too?
>
> No, no, no, yes, depends. You can only mock an interface, not a class.
With certain mocking frameworks anyway...
Its sometimes beneficial to derive from a class and over ride its
methods to serve like a Fake or Mock.
>> List webforms = new List();
>>
[quoted text clipped - 3 lines]
> understand my requirements before suggesting that what I'm doing is
> incorrect.
Yes, sorry, thats not what I was trying to show. I was merely trying to
show that a (actually ArrayList - missed that above) list can be created
without any elements, and its current implementation would satisfy the
isEmpty(). But then I could be missing some point about your usage of
the list - you haven't made it clear...
> I'm testing a class that checks a List for whether it
> contains any elements and branches based on that. I have no need for
[quoted text clipped - 9 lines]
> you're suggesting, I have to create *more* objects if I want isEmpty()
> to return false. With mock objects, I don't.
What more objects? its one ArrayList object containing nothing.
Thats the same as one MockList containing nothing.
>> I understand the benefit of mocks, we can prime them for expected
>> behavior calls and values. Though I'm at a loss to understand why you
>> need to mock a list....
>
> That's because you don't seem to understand my requirements, which is
> understandable.
>> Mocking any Java class is rare (though not non-existent) in the junit
>> community.
>
> Rare based on what metric or study?
Based upon neither...just personal long standing usage of JUnit,
coaching of TDD using JUnit and discussing it on various JUnit forums.
If you haven't come across it, I can recommend the JUnit Yahoo group.
You'll find many good people there willing to help, including the JUnit
authors (Beck et al) and various book authors...
>> Just curious you see...
>>
[quoted text clipped - 4 lines]
> Nah, save yourself the effort. What you're suggesting provides no
> benefit and involves creating more objects than is necessary.
right - o
> The one example I provided is hardly a good example anyway. HttpServletRequest
> is a better example and is also a Java class.
What about HttpServletRequest?
Mocking it?
Darryl L. Pierce - 04 Jan 2006 23:35 GMT
>>> Do you mock String, Integer, Boolean, Map, etc, too?
>>
>> No, no, no, yes, depends. You can only mock an interface, not a class.
>
> With certain mocking frameworks anyway...
But not with what I'm using.
> Its sometimes beneficial to derive from a class and over ride its
methods to serve like a Fake or Mock.
Except when that other class is also one that's tested in your project,
in which case you can't be assured that a failure is a result of the
class you're testing or the one you're using to do the testing. Also
your method does not give me any guarantee that any particular method
(such as isEmpty() in this case) was even called in the first place.
EasyMock reports the test as a failure if the methods you expected to be
called weren't called. Stub objects do not do that for you unless you
first write *even more code* to track that. And now you've created even
*more* work just to accomplish a unit test.
>>> List webforms = new List();
>>>
>>> assertTrue(webforms.isEmpty());
>>
>> I'm not testing that. That's why I said previously that you ought to
understand my requirements before suggesting that what I'm doing is
incorrect.
> Yes, sorry, thats not what I was trying to show. I was merely trying
to show that a (actually ArrayList - missed that above) list can be
created without any elements, and its current implementation would
satisfy the isEmpty(). But then I could be missing some point about
your usage of the list - you haven't made it clear...
I've made it abundantly clear: the class I'm testing will call the
isEmpty() method on the List it has and branch based on whether it gets
a true or a false back.
>>> whats the difference you see between that List and your mock list -
you still have to create an instance of your mock list.
>> And I can script the responses that the mock object returns without
having to create any *more* objects. One mock and I'm done. With what
you're suggesting, I have to create *more* objects if I want isEmpty()
to return false. With mock objects, I don't.
> What more objects? its one ArrayList object containing nothing.
I don't just need a List that contains nothing. I also need to test when
isEmpty() returns *false*. In order to do it your way I need to create
*more* objects and put them into the List, objects which themselves will
never be used in my unit tests. Creating objects that will never be used
is a waste.
> Thats the same as one MockList containing nothing.
Mate, I've said a few times that that's not the *only* List I'm using.
>>> Mocking any Java class is rare (though not non-existent) in the
junit community.
>> Rare based on what metric or study?
>
> Based upon neither...just personal long standing usage of JUnit,
coaching of TDD using JUnit and discussing it on various JUnit forums.
So you mean *you* don't do it? Okay, then say so. My experience is
different from yours: all I've ever seen have mocked anything that was
not directly being tested.
> If you haven't come across it, I can recommend the JUnit Yahoo group.
Already a member.
> You'll find many good people there willing to help, including the
JUnit authors (Beck et al) and various book authors...
I have _JUnit In Action_. I'm not ignorant of JUnit, thank you.
>> The one example I provided is hardly a good example anyway.
HttpServletRequest is a better example and is also a Java class.
> What about HttpServletRequest?
>
> Mocking it?
Yes. It's a Java class. Simply creating a stubbed version of it is a
whole extra programming effort. If you're testing a servlet is it really
more practical to create a scaffold version of HttpServletRequest? What
do you do about the contained HttpSession? If your unit test touches it
then you now have to stub that as well. With Easy Mock you can mock the
whole lot of those objects and pass back and control the whole situation.
Again, the whole point I'm making now is that dismissing mocking
Collection interfaces or anything else that's "a Java class" or saying
that "we don't need to mock things that work" is short sighted. Mocking
objects is a means to an end and not the end itself, and creating a real
instance of the type rather than using a mocked version just because
it's part of the Java API is not necessarily the right/better way, nor
is mocking them automatically the wrong/worse way. As long as the
desired outcome's achieved, then it's that's what matters. And if it's
done in the fewest lines of code or in the simplest, least complicated
way then you have a better assurance that your test isn't being
influenced by possibly buggy testing code, something which is more
likely to happen if you're writing extra classes *just* for the tests to
consume.

Signature
Darryl L. Pierce <mcpierce@gmail.com>
Homepage: http://mcpierce.multiply.com/
"McVeigh's lawyer got him the death penalty, which, quite frankly,
I could have done." - Jon Stewart
Andrew McDonagh - 04 Jan 2006 23:41 GMT
> I have _JUnit In Action_. I'm not ignorant of JUnit, thank you.
wasn't trying to imply you were..., I'm curious as to why you wanted to
do it that way... thats all. Call it a learning exercise for me if
you'd like.
Darryl L. Pierce - 05 Jan 2006 00:19 GMT
>> I have _JUnit In Action_. I'm not ignorant of JUnit, thank you.
>
> wasn't trying to imply you were..., I'm curious as to why you wanted to
> do it that way... thats all. Call it a learning exercise for me if
> you'd like.
K, no prob. :)

Signature
Darryl L. Pierce <mcpierce@gmail.com>
Homepage: http://mcpierce.multiply.com/
"McVeigh's lawyer got him the death penalty, which, quite frankly,
I could have done." - Jon Stewart