>
> >Marcus always has good ideas. I'm a little surprised at his apparent
> >dislike of testing, [...]
>
> I don't dislike testing!!! I have *NEVER* said that!
Never believed you disliked it...well, no more than any engineer, it does
get irritating taking time to do good tests...if you're like me, you'd
rather be developing new code than developing tests for old code. But
I thought you'd like to be aware that your previous posts were _sounding_
like you didn't like testing.
>
> I dislike things that are expensive and don't work in
> the real world: like formal methods, especially when they are
> held up as a paragon of how to do something right, when in
> reality they amount to doing nothing. :) You CANNOT prove an
> absence of bugs. They teach you in logic 101 that you can't
> prove a negative - so let's focus on engineering things to
> be robust, fail safely, and have backup safe failure modes.
Yeah, the part of the good doctor's discussion I liked though was about
stress testing. It's not like we're selling people editors here, they're
putting the security of their companies in our hands.
>
> I'm a big believer in practical testing. That means
> you test the HELL out of stuff you know from real life experience
> is likely to break. For example, smb pointed out to me that
> resource starvation in firewalls might cause a bad situation
> where netperm-table is read, and when a proxy tries to map a
> username to a uid to do a setuid to a non-prived user, it
> might fail due to insufficient file descriptors and not do
> the setuid. That's why there are checks for all relevant
> system errors in the proxies. [check lib/mapu.c - it hasn't
> changed since the first version of the toolkit and it checks
> for exactly that. amuse yourself by seeing what happens to
> the proxies if calls to mapuid fail]
I ALWAYS test the ones that are likely to break...these aren't the ones
that bite my butt though, it's the weird unexpected ones that get me.
Stress testing shows up some of those. When I'm in a position to have
someone that does testing for a living I'm always happy, because they
don't care what's likely to break. They just care about what's possible.
They don't have the blinders that I have built from the same things I
"know" to be true about my code and the environment it runs in. When
I pass the code to them I've _always_ tested all the things that are
likely to break. I'm one of the most defensive programmers I know. I
check everything in the code, then as each part is developed test it
to make sure it works like I expect it to. Nevertheless, between
testers, and purify, I invariably find I missed something.
I cut a section next where Marcus goes on in a great discussion of how to
lock a process in a chroot'd jail. I didn't have any comments to make on
it so I thought I'd save the bandwidth.
Patrick
_______________________________________________________________________
/ These opinions are mine, and not Amdahl's (except by coincidence;). \
| (\ |
| Patrick J. Horgan Amdahl Corporation \\ Have |
| patrick @
amdahl .
com 1250 East Arques Avenue \\ _ Sword |
| Phone : (408)992-2779 P.O. Box 3470 M/S 316 \\/ Will |
| FAX : (408)773-0833 Sunnyvale, CA 94088-3470 _/\\ Travel |
\___________________________O16-2294________________________\)__________/
|
|
