Unit testing - suitable for all development?

"Kylotan" <kylotan at hotmail.com> wrote in message
news:153fa67.0403070839.77ae66e6 at posting.google.com...
> Today I tried to implement some sort of unit testing into my program> for the first time, and must admit to being a little disillusioned> with the process. Mainly, my issue is that in my program, the classes> are so tightly coupled that testing in isolation is next to> impossible.>> The main problem stems from the fact that I try to ensure that all my> objects are created in a working state. This often means passing> various other objects to the __init__ function. In turn, these other> objects rely on others, and on general initialisation procedures. The> end result is that there are very few objects I can truly test in> isolation; I have to initialise at least 80% of the system before I> can even create most of my objects. This ends up meaning that unit> testing isn't really testing a single unit at all, and in fact isn't> much more precise than liberally using asserts in the normal code.>> One way out of this would be to reduce coupling. This would allow me> to test objects in relative isolation, but it would increase the> amount of explicit coupling code that I'd have to execute normally.> This extra code then becomes a potential source of new bugs.>> Has anybody else come to similar conclusions?

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.

I'm very much a fan of creating objects in a state so that
the object invariants pass. I've got two suggestions.

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.

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.

John Roth
>> -- > Ben Sizer