As someone once pointed out to me when I was on a jihad for
error-checking/returning in a code development project, it's the things
that you *know* might break that you can slow down your code by putting
RC evals (evals are always very, very slow) to report on, but you
generally check for them *anyway* in your testing process...so why put
them in?....it's the stuff that you never thought of (and couldn't put
RC checking in for) that will break and bite you in the ass and leave
you wondering WTF is going on
Timo Sirainen wrote:
On Tue, 2009-01-27 at 11:21 -0600, Eric Rostetter wrote:
Quoting Timo Sirainen <t...@iki.fi>:
Something automated. There are several different testing
possibilities actually. Unit tests is one thing.
Last time I brought this up, it lead to so much endless arguing/debate
over what type of testing to use, what toolset to use, etc. that nothing
ever happened.
Why don't I remember the arguing? :) Maybe I was just following to see
what's going to be the result and it eventually died out and I thought
people just lost interest.
I'd still be willing to do unit tests, if there is no longer any
arguments from others to stop it. I'm open to suggestions as to
tools to use and such as long as it isn't a flame war...
I've already written some unit tests in src/tests/. I don't really care
if you continue them the way I started or use some other toolset. And
unless someone else is also willing to actually write the tests, I don't
think you should care all that much about their arguing.
--
==== Once upon a time, the Internet was a friendly,
neighbors-helping-neighbors small town, and no one locked their doors.
Now it's like an apartment in Bed-Stuy: you need three heavy duty
pick-proof locks, one of those braces that goes from the lock to the
floor, and bars on the windows.... ==== Stewart Dean, Unix System Admin,
Bard College, New York 12504 sd...@bard.edu voice: 845-758-7475, fax:
845-758-7035
