Jeff D. Chastain wrote, On 12/22/2006 9:39 AM:
Sam,
Yes, what I thought I said was that test drive development was to
write the test the object you are working on before you create that
object. The problem comes in when that object then depends upon
another object, etc. etc.
If you check out the Martin Fowler link that Paul posted earlier, it
discusses very well two possible testing approaches ... state based
and interaction base. State based testing tests the entire depenendcy
tree in one test. Interaction based testing focuses only on testing
the specific object and its functionality. As stated in Wikipedia,
unit testing really follows Fowler's definition of interacton based
testing.
I read it and I guess I'd consider myself more of a "state based tester"
than interaction based. I have used stubs on occasion, and like he
mentions (and as did I), there are typically few of them, so no need for
mocks if you prefer to test that way.
This is the way I would prefer to test as I can quickly pin point
exactly where an issue is rather than having a dozen tests fail with
different errors because one object they all depened upon had an issue.
That's fine. I was simply telling the story of how I practice TDD. If
you prefer to use mocks, I certainly have no problem with that! =) I
also said I've yet to run into the potential problems you described (and
apparently, a lot of people don't, otherwise I would assume everyone
would be recommending interaction based testing all the time). But,
also a lot of people prefer to use mocks. There are smart people on
both "sides of the isle" so to speak.
I haven't found that I often get a lot of tests failing because of one
object they depend on being broken. I have had it happen, of course,
but even when it does, I've never run into a problem figuring out who
was the culprit. But, I've only been doing this for just under a year,
and even if I had been doing it 10 years, I'd still think that other
people have different experiences and I'd recommend they use the style
that they find the most benefit in.
Mock objects (and stub objects) fit into the interaction based testing
model in that they allow you to stub out the interface of the
dependent object, making the assumption that it works as it should and
therefore focusing your testing on the single object at hand. Mock
objects take a stub object one step further and allow you to perform
additional assertions as to whether the depend object's interface is
being utilized correctly ... in other words, if function X was called
3 times, was passed a single integer, and function Y was not called at
all.
Yes, and now that I see Robert Blackburn has introduced mocks into
CFUnit, I will be using them for stubs on my db calls for objects that
use others who access the database. But, I expect I'll still be using
state based testing, as like Martin Fowler said in that article,
"Personally I've always been a state-based tester and thus far I don't
see any reason to change. I don't see any compelling benefits for
interaction based testing, and am concerned about the consequences of
coupling tests to implementation. I also suffer from the disadvantage of
not trying interaction based testing on anything more than toys."
However, unlike him, I can see some "compelling benefits," at least for
some cases that I would have liked to know how many times I've called
methodX(). Though, I expect he is pragmatic and would use them if he
found the need - I think he probably just meant something more like "not
enough compelling benefits" or something of the sort.
Testing objects and their dependencies in a "real world" scenario is
not a bad thing at all. In fact, it is called integration testing. I
just want to perform unit testing seperately from integration testing
so that when something crops up in my integration tests, I know that
the individual objects are doing what they are supposed to.
I thought I mentioned that it was called integration testing. In any
case, I had meant to. But, I don't think it's useful in the development
scenario to focus on what to call your tests, so I may very well have
left it out. My apologies if I was confusing, or didn't get my idea
across well. =)
-Sam
-- Jeff
------------------------------------------------------------------------
Jeff Chastain wrote, On 12/21/2006 5:57 PM:
> There is always a need for both unit and integration testing, I just
don't
> like mixing them. Part of test driven development as I understand it
is to
> write the test for the object, then develop the object.
I'm not sure if you meant this or not, but for clarity's sake, I'll
describe it more like "write a test, then make that test pass." The way
I read what you said above, it sounded like "write all the tests, then
write the class."
> How do you do this
> if you first have to write the dependent objects?
You don't first have to write the dependent objects. When you find
yourself in need of one, then you create it. But you don't write the
whole thing. Just stub the method you think you need and have it return
what you are expecting - no real code. When you need real code, you
write the test for it first, as you always would.
> There is a reason for the
> popularity of the mock and stub frameworks in other languages ... it
makes
> testing more precise.
It can do that, yes. But, I'm not sure if that is why they are
popular. Several "thought leaders" in the Agile movement, as far as
I've been able to ascertain, either don't use them as extensively as
some people do (ie, perhaps they'll only mock database calls so the
tests can still run fast, or interaction with the file system, for
similar reasons), or promote them for use in projects that are are
already well established and have no tests. I haven't seen anyone
recommend them just for testing without dependencies. You still are
depending on the mock, after all.
> Yes, you may never run into problems with a dependent
> object breaking the object you are testing, but I don't really see
that as a
> reason to allow the possibility. If it did happen, you could have a long
> dependency chain, part of which you might not be able to test (the event
> object in Mach-II for example) and debugging would be as difficult as it
> would be without unit tests.
>
>
I'm not familiar with Mach-II, but I would have thought long dependency
chains are not generally advisable. And I'm certainly no expert on
that, so I could well be wrong. I can't remember a time when I've had
more than 4 or 5 in a chain though. In either case, it is important to
note that if they would be there without the mocks, they will be there
with the mocks too. And still further, if you had been doing what I
attempted to describe, all of it would be under test (that I can see -
but I may certainly have not explained it well enough, or I could be
missing something). The same cannot be said if you are only using
mocks, however.
Can you provide an example, to help me see it?
> I have just seen a lot more posts recently about unit tests and TDD,
but I
> have not seen any examples short of very simple objects with no
> dependencies.
>
>
Do you have an example you'd like to see in mind? I sat here thinking
of one for a couple of minutes, but I didn't find one in my head. But,
perhaps I can think of one later, if you don't have one in mind.
-Sam
You are subscribed to cfcdev. To unsubscribe, please follow the
instructions at http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com
An archive of the CFCDev list is available at
www.mail-archive.com/cfcdev@cfczone.org
You are subscribed to cfcdev. To unsubscribe, please follow the
instructions at http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com
An archive of the CFCDev list is available at
www.mail-archive.com/cfcdev@cfczone.org
You are subscribed to cfcdev. To unsubscribe, please follow the instructions at
http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com
An archive of the CFCDev list is available at
www.mail-archive.com/cfcdev@cfczone.org
