| Store | Cart

Unit testing - suitable for all development?

From: John Roth <news...@jhrothjr.com>
Sun, 7 Mar 2004 21:47:48 -0500
"Kylotan" <kylotan at hotmail.com> wrote in message
news:153fa67.0403071515.7cf93986 at posting.google.com...
> "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.

Your comment below makes me wonder if you're trying
to create a "text adventure" game. I'm not certain whether
to take it literally or not.

Text adventure games have a real different domain model
from what most object oriented systems are designed for.
Almost all objects are singletons, or else have lots of
behavior in the instances that aren't part of the base
classes. The few people I know of who work on games
have real problems with unit testing gameplay, whether done
before or after the fact. There is a feeling that it's simply
not worth while. Unit testing the underlying engine, though,
is very worth while.

> > 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?

No, I'm talking about layers in the sense that objects
in one layer are not allowed to call objects in higher
layers. Sometimes imposing a layered architecture
clarifies things by forcing the removal of cyclic
dependencies.

> > 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.

Mock objects don't have do-nothing functions. They have functions
that do exactly what the current test needs them to do.

John Roth

>> -- > Ben Sizer

Recent Messages in this Thread
Kylotan Mar 07, 2004 04:39 pm
John Roth Mar 07, 2004 05:48 pm
Kylotan Mar 07, 2004 11:15 pm
John J. Lee Mar 08, 2004 12:28 am
Kylotan Mar 08, 2004 08:22 pm
John J. Lee Mar 09, 2004 08:56 pm
John Roth Mar 08, 2004 02:47 am
Kylotan Mar 08, 2004 09:00 pm
wmwd...@sneakemail.com ) (Greg Ewing (using news.cis.dfn.de) Mar 09, 2004 02:16 am
Roy Smith Mar 08, 2004 03:19 am
Roy Smith Mar 07, 2004 05:50 pm
Kylotan Mar 08, 2004 01:51 am
Cameron Laird Mar 08, 2004 01:17 pm
Lidor Wyssocky Mar 10, 2004 11:38 am
Messages in this thread