On Saturday 08 June 2002 17:32, Adrian Howard wrote:
> I found that, once you have a moderately complex system, it's hard to
> determine whether changes you are being warned about are going to be an
> issue (beyond simple things like method renaming). I spent too much time
> looking at the code,
On Saturday, June 8, 2002, at 07:12 pm, chromatic wrote:
> On Saturday 08 June 2002 11:02, Michael G Schwern wrote:
[snip]
>> 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
On Sat, 8 Jun 2002, Andy Lester wrote:
> * Dependencies should be optionally based on something other than just
> the timestamp of a file. For instance, I suspect I'd like to be able to
> make the date dependency on "SELECT MAX(DateUpdated) FROM Foo".
Hmmm, for example a hash of the code (a la
> I'm a big fan of testing units in isolation. It's easier, faster, and tends to
> more comprehensive and detailed tests. The problem is, if the unit being
> tested has a legitimate dependency on another unit in the suite, isolation
> testing cannot identify interface changes.
I've been vaguely
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
On Sat, Jun 08, 2002 at 11:12:40AM -0700, chromatic 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.
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
> tou
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 se
I'm a big fan of testing units in isolation. It's easier, faster, and tends to
more comprehensive and detailed tests. The problem is, if the unit being
tested has a legitimate dependency on another unit in the suite, isolation
testing cannot identify interface changes.
This has bothered me for
