Hi, [This post has grown out of some discussions with Nick Clark and various other people. If it repeats anything people have said, then can someone point me at the relevant posts. I've had a look through the archives but can't find anything obvious.]
OK, well the basic idea is to have some way of author A being able to submit tests which test a module B which A didn't write. Then, once we have enough non self-authored tests then we could conceive of Kwalitee metrics such as "For modules in the area of 'Databases' which modules a) Have at least four sets of tests which weren't written by the author and b) Have at least 5000 total tests" and this might conceivably be expected to return some modules which might be useful. There are a number of advantages to being able to submit tests separately from modules, and being able to track authorship of tests separately from modules, mostly to do with the fact that many programmers don't test well and that testing by a different person can be better than testing by the author. I can also see a number of problems: * Correctness of tests. For tests bundled into modules it's easy - the tests are correct because the author says so. Once tests are separated from modules this becomes harder and also opens the way for dispute "Module Foo claims to implement RFC XXXX but this test which is clearly according to spec fails for Foo ... " * Management of lots of small, twisty-turney bits of test, all very similar yet all different. Is the module format really right for this? * If Kwalitee metrics are going to boil down to some sort of measure of the perl-fu of the authors of modules (and I can see why this should be so[0]) then testing-perl-fu is going to be different from coding-perl-fu. Anyway, I hope that's a reasonable outline. Well, even if it isn't I think I've probably babbled enough. Ben [0] Basically, I think of the whole Kwalitee thing as a solution to the problem: A perl newbie, who knows how to program in another language / environment (Java, say) wants to build an application in perl but has no exposure to the perl community or way of doing things. They come to CPAN and want to get some packages to base their application on, but don't know which ones to get. CPAN is large and daunting. The solution is that you should probably start with the packages which are relevant to your application design which have highest Kwalitee. High Kwalitee packages are generated by (in theory at least) the most experienced and diligent of Perl programmers.
