On Wed, 20 Jul 2005, Michael G Schwern wrote:
> Also, it eliminates one of the valuable parts of CPAN testers: testing in the
> wild. If you create an artificially clean environment (the clean image),
> then install all the latest versions of dependent modules into it and then
> run the tests you
On Tue, 12 Apr 2005, Paul Johnson wrote:
> I would do it in the same way as if this had nothing to do with tests.
> That is, abstract away the common code into a module, which can also
> live under t/
That would be a lot of work in this case. I found an easier
solution. In tweek-then-foo.t:
Hello all. I've got a test I want to write, but I don't know to write
it (easily). I've got a test script, call it foo.t which uses
Test::More and runs under Test::Harness. Now I want to make a new
test script tweek-then-foo.t which tweeks the system and then ensures
that foo.t still passes. Ho
On Wed, 26 Jul 2000, Dave Paris wrote:
> A patch test should do a minimum of two things:
> (a) prove the existance of the problem *before* the patch.
If the patch solves a problem (versus adding a feature), this is true.
> (b) prove the problem has been fixed *after* the patch - without
> break
