Re: Rethinking how ext/ is tested

2009/2/26 Michael G Schwern <[email protected]>:
> This is annoying and really its unnecessary.  The point of putting non-XS
> modules into ext/ is to reduce the differences between the CPAN and core
> versions.  This goes both ways.  The core is currently cheating in how it runs
> ext/ tests, it's running them manually rather than using "make test".
>
> So I propose changing how the core runs the ext/ tests.  Rather than running
> them as part of one large run, let's take advantage of make and just let "make
> test" cascade down into the ext/ directories.  The t/ and lib/ tests would run
> first, then "make test" would be run in each ext/ directory.
>
> Thoughts?  I'm going to go hack on that.

We have two test frameworks, t/TEST and t/harness.

t/TEST is the simple one, for testing broken things. It has no
dependencies. Most notably, if Test::Harness is broken, t/TEST
still works. Your proposal implies that t/TEST goes away.

t/harness is the complex one, but requires Test::Harness to be
built and installed in lib/ properly. Your proposal implies
that it should be able to collate the results of many sub-runs
in each ext/ subdir. Is this handled already ? That doesn't sound
like a simple thing to do portably.