On Fri, 13 Feb 2015 09:23:58 +0000
Ralph Eastwood <tcmreastwood_AT_gmail.com> wrote:
Hey Ralph,
> Yeah I am reasonably confident after the last patch. Uuencode always
> worked but I had some issues on the uudecode in corner cases (Didn't
> flush the decoded stream in the right places). One of the three
> patches just removed some of the cruft I left behind during testing
> uuencode. I manage to test uudecode on a number of inputs now with
> some large files and different length streams to makes sure each code
> path was tested.
Okay, then I second this patch to be merged asap.
> For code like this - should we have some regression testing (perhaps
> in a separate testing base), to verify POSIX compatibility? For
> instance, sbase ls still has a bug with directory listing output.
I have a mixed opinion about test-environments. In my opinion, they
become necessary when the developer can't grasp the complexity of his
program and needs to check if certain vectors passed to his program
result in the same output vector as expected in the standard.
However, this doesn't assure deviations don't happen. It's much better
to look at the code again and rewrite it in a shorter and concise way.
This is not the case anymore in big commercial programs, but this is
far from the desired state. A modular approach, where you can assess
that each part works as expected, can be way superior.
If you make a change to a tool and can't be sure that it modifies
edge-cases, there's something wrong with the program.
Take libutf for example, which I had the honor to work with the last
few days.
http://git.2f30.org/sbase/commit/libutf?id=73577f10a0076dfa361776ead28621f59772154c
The time spent to refactor this function, courtesy to Connor, would
have been wasted on writing a testcase for given function or tool based
on it.
That's the reason why I'm and many others are personally against
test-driven development:
Because it shuts off the part of your brain which helps you keep track
of your things, and often you are urged to fix problems in only such a
way that it fixes the test-case, but uglifies the code and brings new
problems not covered by your testing environment.
Cheers
FRIGN
--
FRIGN <dev_AT_frign.de>
Received on Fri Feb 13 2015 - 10:41:08 CET