On Sat, Jun 08, 2002 at 10:45:50AM -0700, chromatic wrote: > Taking an average test suite as an example, we could have 'foo.t' and 'bar.t', > testing Foo.pm and Bar.pm respectively. Bar depends on Foo, and bar.t mocks a > couple of methods of Foo. > > If bar.t uses Test::Depend, it'll pick up several things: > - the module being tested (assumed from a use_ok() or require_ok() call) > - the module being mocked (assumed from an entry in %INC) > > If there's no dependency information, it'll use the current version of Foo.pm, > the last modified timestamp of the test file, and the test status of foo.t (if > it also uses Test::Depend) to keep track of any changes to Foo.pm. > > 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 Perl had strong interfaces, like Java, this could be done a bit more intellegently. But it doesn't. In reality, if Bar.pm changes in an incompatible way Foo.pm's own tests should fail and that should cover you. > Like I said earlier, I'm aiming for an 80% solution. There are some > assumptions and some fragilities here, but it represents a great improvement > over the current system, in my mind. -- This sig file temporarily out of order.
