Unit Tests: No really, you HAVE to use them

twisted :: programming :: testing

So, for the pycon sprint this year, I figured I'd work virtually
with some other developers who couldn't make it this year. There has
been some interest and requests on the pymon mail lists... I strongly
believe that patience and loyalty should be rewarded, and these guys
have put up with an awful lot of delays and bugs... and circumstances
beyond anyone's control.

The first thing I wanted to do was get a usable release candidate
available for them to download. After digging back into the code, I
realized that the best way to provide this was by patching up the
already-extant pymon RC2. With RC2 operable, I tried fixing some bugs
for later code changes, and I couldn't. The code was a mess. But not
anything most people would ever notice or even care about.

Here's what I mean: in the last big merge, we brought in all the
twisted code, and then proceeded to clean that up... but people wanted
to use it soon, and writing tests slowed us down, so we skipped it. It
is debatable whether that was the right thing to do, since it is really
important to weigh your user base when making such decisions. Being a
purist at heart, I'm really wishing it was possible to have pleased the
users and take the time needed to add the tests. Regardless, I have to
add them now. The project simply will not progress without it. I cannot
currently debug effectively without them.

But there is something more important here, the REAL reason I need to
add unit tests. When I tried to add them yesterday, I realized my code,
as it was, simply wouldn't allow it. This means my code is bad. Plain
and simple. It means that there really aren't "units" to test, and that
means the code is not well-enough thought out. After looking at the
problematic code yesterday, it appears pymon will be a good candidate
for componentization. This will:

1. Provide clear units than will be much more easily testable as
   units


2. Clean the code up considerably


3. Come more in line with the standards and best practices of the core
   twisted code

By adding unit tests early on in a project's life, you are giving
yourself the chance to benefit from a design litmus test. If your
twisted code lends itself more or less easily to twisted.trial, then
there is also a good chance that you have something that is workably
modular. For me, this will mean that I can accept all sorts of feature
additions and increased application sophistication without affecting
the quality, readability, or testability of the code. The code will
remain clean and simple. There will just be an increased number of
components.

Now playing:

Yes - No Opportunity Necessary, No Experience 
Needed