On Oct 25, 2007, at 9:32 AM, Bob La Quey wrote:
The point that I am getting at here is that unit tests do define the code. They define the units. If the code is very poorly designed then the units are wrong.
This is where refactoring comes in, isn't it?I would still think you'd want a unit test to determine if the existing code works at all, and test the fixes. You'd then decide how the replacement code should work, write a unit test for that new behavior, and then code to the test.
I don't see what all the fuss about unit testing is (from the "waaaa, i hate unit tests" side). What's so hard about defining, in a pass/ fail manner, what outputs should come from given inputs to a module of code? That, really, is the core of unit testing, isn't it? Essentially QA in code.
Lack of QA leads to complacency and reliance on the end-users to report problems that should have been obvious to the development house.
Personally, I've never done unit testing before. I'm finally working on a personal project large enough that I need it to keep my sanity, and am starting to look into how to do it properly. Given the size of some of the code, I'd be lost without having something like unit testing to help me make sure I'm actually coding things correctly.
Gregory -- Gregory K. Ruiz-Ade <[EMAIL PROTECTED]> OpenPGP Key ID: EAF4844B keyserver: pgpkeys.mit.edu
PGP.sig
Description: This is a digitally signed message part
-- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
