[Twisted-Python] Re: [Twisted-web] CPUShare-Twisted

Samuel Reynolds sam at SpinwardStars.com
Sun Jan 22 20:10:24 EST 2006


At 2006-01-22 07:52 AM +0100, you wrote:
>My developmnt is generally test-driven. I'm only opposed to unit-test
>mandatory development to fix bugs or add new features.

Just my 2 cents worth:

It might help if you think of it not as a unit test,
but as a simplified test program that demonstrates
the failure. If you understand the problem, it's
generally possible to create a simplified program
that captures its essence for others to understand.

>Writing unit-test
>isn't the only way to test code. It's nice to have a unit test, even a
>simple one, but it shouldn't be mandatory.

Automated unit testing *is* the only way to *effectively*
test code. It's also the only way to ensure that someone
doesn't make a change at some later date that re-introduces
a bug; the unit test will point the finger at the guilty
party and the (newly-)broken code.

In fact, even if you don't write a unit test case or
program, you are doing unit testing when you duplicate
and report a bug.

You're either unit testing using automatic testing
methods (i.e., a test program) or you're unit testing
manually. Guess which tests will actually be run?

You're either unit testing a constrained chunk of code
with a limited, reasonably-well-defined range of behavior,
or you're unit testing a larger system with a wide range
of behavior and trying to determine, from the aggregate
behavior, whether a small change somewhere has changed
the system's behavior in an undesired fashion.
Guess which test will efficiently catch problems?

*Without* automated tests, you're testing the system
instead of the module--which is far less effective--
AND you're doing it manually--which means the test will
probably never be repeated to verify behavior after
some *other* change is made.

If you want stable, dependable code, WRITE THE TEST CASES.

Further IMO:

As a *user* of a variety of development tools and libraries
who *knows* how difficult it can be to duplicate a bug,
I always try to create a test program that demonstrates
the bug, and which can either become a test case or be
used, in whole or in part, to create a test case.

As a professional software developer, I automatically
reject any bug report (from the QA folks) that doesn't
provide sufficient information to duplicate a bug.
QA personnel are paid to find and document bugs; if
they don't, it's their problem, not mine. On the other
hand, I know that "users" of an open-source module
generally don't think they signed up to do QA (though
it's implicit in the open-source development model).

As someone who has released open-source software in the
past, and plans to do so again soon, the presence or
absence of a test program (AKA unit test) that demonstrates
a bug is often the deciding factor when I devote some of
my limited time to fixing bugs. Practical considerations
(mainly available time, but interest as well) tend to
result in the issue going to the end of the queue, and
therefore never being addressed (without a specific
need on my part).

So I see no reason why a unit test or test program
should not be required. Twisted, like most open-source
development projects, is a *cooperative* development
effort. And, as find myself telling my coworkers *far*
too often, if the code isn't tested, there's no
assurance that it works as intended or designed.

FINALLY (I sincerly hope!):

More generally, I think everyone on the list is now
well aware of both the range of opinions and the
Twisted requirements WRT test cases for reported bugs.
The project is Twisted, and has guidelines for
participation; it's to everyone's benefit to follow
the guidelines.

Now...
Can we PLEASE agree to disagree, stop sniping,
and devote mailing list bandwidth to "real" issues?!

- Sam

__________________________________________________________
Spinward Stars, LLC                        Samuel Reynolds
Software Consulting and Development           303-805-1446
http://SpinwardStars.com/            sam at SpinwardStars.com 






More information about the Twisted-Python mailing list