On 10/20/2003 2:41 PM, Tony Bowden wrote: > On Mon, Oct 20, 2003 at 07:02:56PM +0000, [EMAIL PROTECTED] wrote: >> >> If the code has been properly designed (i.e. factored into separate >> pieces without lots of ugly interdependancies) it should be >> possible to run the module-level test for that piece when it >> changes, not the full- out test suite for the entire product. > > Surely this is only true if no other module in your system interfaces > to this in any way.
Okay, perhaps the bias of my background is showing through. Most of my work is in embedded systems (not Perl) where code modules are indeed largely independant. We do module level testing for most changes, and then later (at release time) do a higher-level integration test to ensure that everything works together. Even without that situation, I don't think that you necessarily have to test everything that has an interface to the modified code. For example, the changes being tested could be a new faster algorithm that doesn't (shouldn't) have any externally visible effect. *If* you have a good module-level test suite, you should be able to run just that and verify that all your tests still pass and you haven't changed the observable behavior. Of course, if the change is a bugfix in a library module, I agree with you completely. > You can layer the code such that changes to code at the "top level" > don't need to run the tests on "lower" code, but changes to that > "lower" code will always need to be checked by re-testing the > "higher" level code. I hate that ripple effect. :) -mjc
