Re: Unit testing - suitable for all development?
From: Kylotan (kylotan_at_hotmail.com)
Date: 03/08/04
- Next message: simon place: "Re: machine control script ( parameterless method? )"
- Previous message: Peter Otten: "Re: How do I define a __del__ method for an object?"
- In reply to: John Roth: "Re: Unit testing - suitable for all development?"
- Next in thread: John J. Lee: "Re: Unit testing - suitable for all development?"
- Reply: John J. Lee: "Re: Unit testing - suitable for all development?"
- Reply: John Roth: "Re: Unit testing - suitable for all development?"
- Reply: Roy Smith: "Re: Unit testing - suitable for all development?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 7 Mar 2004 15:15:07 -0800
"John Roth" <newsgroups@jhrothjr.com> wrote in message news:<104mo6mjpc1lq74@news.supernews.com>...
> Coupling is the enemy.
>
> The XP people have a lot of experiance with reducing
> coupling. Writing tests first, and insisting that literally
> hundreds of unit tests run in a few seconds teaches you
> how to write code with a minimum of coupling. Some of
> those lessons aren't particularly easy.
Yeah, that's what I'm guessing. I'm at the stage where I have to
wonder whether forcing myself to make the paradigm shift will be worth
the effort or not.
> The first is to see if you can redesign using a layered
> architecture. That may force you to reduce the number
> of objects that any given object depends on.
What do you mean by layered in this context? Are you talking things
like the Bridge design pattern?
> The second is to investigate mock objects, or other
> methods of stubbing out dependencies. While you do
> need to run the entire system as a unit, there is no
> reason you need to run the real production objects
> for all tests.
That seems like a nice idea, but I've been developing this system as
an evolving prototype. I add new objects and classes as I discover I
need them. Therefore there's almost no functionality there at all that
isn't needed for the system as it stands.
Here's an example of my current system: the Creature class requires a
Race class and a World class to be instantiated, as the Creature's
__init__ function relies on calling methods of these objects (not just
on their presence). Sure, technically I could create dummy objects to
pass in that have do-nothing functions, but then I break most of
Creature's accessors, which are implemented in terms of delegating to
the other objects. In turn this would make the tests meaningless.
I guess what I'm trying to say is that I create systems that arise
from the grouping of classes, and that taking the class out of context
makes it useless. I don't have many things that are low-level enough
to make sense when tested in isolation. (This contrasts heavily to my
development in C++, for example.) And the classes have very little
internal behaviour; it's all done in terms of other classes.
None of this makes testing any harder or less useful in catching bugs;
it just means that it ends up being an almost straight duplication of
my normal code, with the input handling stripped out! It hardly seems
worth the effort.
-- Ben Sizer
- Next message: simon place: "Re: machine control script ( parameterless method? )"
- Previous message: Peter Otten: "Re: How do I define a __del__ method for an object?"
- In reply to: John Roth: "Re: Unit testing - suitable for all development?"
- Next in thread: John J. Lee: "Re: Unit testing - suitable for all development?"
- Reply: John J. Lee: "Re: Unit testing - suitable for all development?"
- Reply: John Roth: "Re: Unit testing - suitable for all development?"
- Reply: Roy Smith: "Re: Unit testing - suitable for all development?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
