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 tss@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 sdean@bard.edu voice: 845-758-7475, fax: 845-758-7035