Unit testing - suitable for all development?

[Kylotan]

"John Roth" <newsgroups at jhrothjr.com> wrote in message news:<104nnqlq81dvj48 at news.supernews.com>...

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

Well, it's a graphical game. There are many similarities to text games
but also quite a few differences, such as input handling and sound
often being dependent on the display being set up, for instance.

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

Well, I have a few singletons (although I don't enforce this
constraint) but the majority of objects come from classes that are
instantiated in large amounts. I enjoy many of the benefits of object
orientation but it certainly is a long way from any sort of
swappable-component system.

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

Ah, got you. Well, I've already gone to some lengths to achieve this.
I think the problem I have is not so much that any one class is
dependent on a lot of other classes, but that it's totally dependent
on one or two. And that one in turn is totally dependent on another,
right throughout the system. It's more of a chain than a web if that
makes any sense, but breaking the chain breaks the semantics, leaving
me very little to meaningfully test.
 
> Mock objects don't have do-nothing functions. They have functions
> that do exactly what the current test needs them to do.

I guess I just can't see any way in which I could create mock objects
for these tests that could provide reasonable behaviour for these
tests, and yet still have no dependency on other objects. Right now,
almost all my methods are of one of two types:

- Simple get/set style. I can keep these valid with assertions inside
the method. Occasionally there's an extra multiplication or level of
indirection here but it's (deliberately) kept so simple that there's
no chance of error.

- Interactions with other objects. These are meaningless without the
other object's methods and state.


I don't have any complex functions that perform some important
mutation of the object's state which can be verified as being correct
at the end with minimal interaction with other objects. It just
doesn't happen at the moment.

I'll revisit the testing strategy once I have significantly more
functionality. Maybe it'll make more sense then.

-- 
Ben Sizer