On Saturday 08 June 2002 11:02, Michael G Schwern wrote: > > If this dependency information changes, it'll fail a test (or maybe warn) > > because there's a potential interface change that Bar.pm may need to > > know.
> It looks interesting up to this point. Basically, everytime Bar.pm is > touched, edited or upgraded, the test will fail. Every doc patch, typo fix > and minor upgrade. This will produce orders of magnitude more false > negatives than real failures, which will sap the credibility of the test > causing it to be ignored. If these cause a version number bump, yes, that'll be a problem. I was unclear, though. My plan is to use the test for the unit *providing* the dependency as the most accurate sort of information. The heuristic might be, in order of ascending importance: - version number changes in the dependency module may mark a change - timestamp changes of the test file probably mark a change - a change in the number of tests (expected/passing/failed/skipped) marks a change That gives me three levels of certainty. The important thing is that it uses the depending module's tests to be more sure if something has changed. > In reality, if Bar.pm changes in an incompatible way Foo.pm's own tests > should fail and that should cover you. Not in a strict isolation testing environment, where I don't want to use the real Bar.pm when testing Foo.pm. Maybe I'm being too strict about my isolation, but it's had good results for me so far. -- c
