Unit testing - suitable for all development?

[Kylotan]

"John Roth" <newsgroups at jhrothjr.com> wrote in message news:<104mo6mjpc1lq74 at 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