2009/2/26 Michael G Schwern <schw...@pobox.com>: > Rafael Garcia-Suarez wrote: >> 2009/2/26 Michael G Schwern <schw...@pobox.com>: >>> 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/TEST would still run the t/ and lib/ tests. So all of the tests of core > perl functionality are still run with t/TEST. That's all left as is. > > >> 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. > > Oh no, just using normal recursive make. > > test: perl-test ext-test > > ext-test: > cd ext/Attribute-Handlers && $(MAKE) test > cd ext/ExtUtils-MakeMaker && $(MAKE) test > cd ext/Errno && $(MAKE) test > ...and so on... > > Each test will show up to the user as an individual test run and result, > rather than the huge block of tests we get now. This is visually unappealing, > and maybe we can do something to make it a little nicer, but that's how > recursive make works everywhere else including MakeMaker. > > Like anything else in make, if any of the subtest commands fail the whole > thing will fail.
Id prefer we find a different solution. Im not sure what it is, but having the tests all run in one block is a very desirable feature. What you are saying is that to know what is broken we have to review many test summaries, this sound sensible if you are thinking about tests only being broken in your module, but its not sensible when a core change has broken a nice chunk of the modules out there. You want to be able to look at one summary at the bottom of all the failures. Reviewing a stack of summaries with different counts and etc doesnt sound fun. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
