Unit testing - suitable for all development?

[Kylotan]

Roy Smith <roy at panix.com> wrote in message news:<roy-5F604D.12502107032004 at reader2.panix.com>...

> you might even be able to get away with no FooStub class at all, but 
> simply instantiating your Bar test object with a constant:
> 
> def setUp (self):
>    self.bar = Bar ("foo")
> 
> This is where the dynamic nature of Python really shines.  Something 
> like C++ or Java would make you jump through a lot more hoops to make 
> sure you instantiated your Bar with a valid Foo.

Yeah, this is true. One of the favourite parts of my system is how I
have a chain of delegation that passes down a 'graphic' object, and
nothing except the two classes at the end of the chain need to know
what type it is.

However, as I think I mentioned in a previous reply on this thread,
all my methods are there because they're the minimum that I require
for valid functionality. Stubbing any of them out would make testing
pointless.

Personally, I don't consider my design to have 'high coupling'.
However, each coupling is essential. For example, much of my design
involves delegation; Class A calls an accessor in Class B which gets
the information from a contained Class C behind the scenes. This
design is explicitly there so that I have no dependency between A and
C. However, it also means that I can't test B fairly without C.

Maybe I just have no code that can be tested in isolation. In all
fairness I don't have much significant code written yet. But as I
thought you were supposed to code test cases as you go along, I
thought I'd start now. But in fact it's proven to be pointless.

> But the basic 
> principle is the same in any OOPL; the more tighly coupled your classes 
> are, the more difficult it is to test, maintain, and understand the 
> system.

I see one major difference here, though. In C++ I have to write lots
of low-level classes to encapsulate various elements of functionality.
These often have few or no dependencies and can be tested in
isolation. In Python I don't need to write these low level classes, as
the advanced syntax solves many of these problems for me. Generators
and list comprehensions replace the need for many function objects.
Tuples replace ad-hoc structures for returning multiple values.
Dictionaries replace many of my C++ storage structures. All the
low-coupling classes I used to write in C++ have been factored out of
the system by the Python language. All that remains is the core of my
system; a few specialised classes working in tandem.

As I see it from my -very- limited experience of this one program I'm
writing, the paradox is that Python makes unit testing so much easier
and efficient, while making it less and less important to me.

> One way or another, your classes need to interact, and the code that 
> implements those interactions needs to exist (and thus needs to be 
> tested).  The question is, where do you put that code?  Do you bury it 
> inside the classes, making it difficult to test both the underlying 
> classes and their interactions, or do you factor it out to someplace 
> where you can test each piece in isolation?

There's nowhere it can go that allows for such isolated testing. The
coupling has to be done in order for the object to make sense. The
only methods that don't involve other objects are trivial ones that
are shorter than the associated test case would be.

-- 
Ben Sizer