On Saturday 08 June 2002 11:39, Michael G Schwern wrote: > It gives you three levels of uncertainy. If Bar.pm is being actively > developed, the tests and version number will be changing constantly and the > dependency check will also be constantly "failing", causing it to be > ignored, or only given a cursory glance.
> If Bar.pm is relatively static, ie. from CPAN, failures will be rare but > when it does fail, it will still be false orders of magnitude more often > than it will be true. Since the developer will have to go in and check if > the API has been broken *by hand* they will rapidly tire of it and begin > ignoring it, or only giving it a glance. Realistically, the best you could > expect is for the developer to look at the module's change log and see if > there's any flashing "THE API HAS CHANGED" lights. I see where you're coming from. It sounds like there are three possibilities for a dependency: 1) It's under active development, so it will change fairly frequently. 2) It's supplied by a third party, so it should be treated as a black box and should be upgraded only after careful human testing. 3) It's in maintenance, so changes are relatively few. I agree with you about #1. Unless Test::Depend is amazingly brilliant about identifying the appropriate bits-of-a-unit level dependencies, it'll produce too many false positives. That's counterproductive, and worse than useless. I don't really care about #2, because a good development process ought to manage it. I'm trying to solve #3 right now. It's intended to say, "Hey, you changed Foo.pm. You (might|should|need to) check Bar.pm, Baz.pm, and Fluxx.pm to see if they need similar changes." I have some ideas as to how to approach #1, but it'll require more human intervention and it's more difficult. It looks like it'll have more benefits, though. > > Not in a strict isolation testing environment, where I don't want to use > > the real Bar.pm when testing Foo.pm. > I presume you're refering to things like IO::Socket and friends that are > frequently mocked? Exactly. There are at least three somewhat overlapping classes of dependencies I usually mock: things I don't want to communicate with the outside world, things that mutate important data (data sinks and data sources), and things that are hard to control for testing purposes (sockets, timeouts, deaths, and other exceptional conditions). -- c
