Quoting brian d foy <[EMAIL PROTECTED]>: > In article <[EMAIL PROTECTED]>, Nathan S. > Haigh <[EMAIL PROTECTED]> wrote: > > > A suggestion was to have different levels of > > "strictness" in Test::Kwalitee and have different sets of metrics being > > tested by > > default at each of those levels. However, I didn´t get into this and simply > > hard-coded some of the metrics to be skipped. > > I think that's a bit out of Test::Kwalitee's scope. It basically wraps > each of the metric code refs in the testing framework and provides > access to those things individually. It's then up to the user to decide > which functions he wants to use. > > I'd leave Test::Kwalitee just like it is, feature-wise, and not have it > dictate use or practice. Let it just provide the ability. Sub-classes > and user classes, which probably have a much better chance of being > maintained, should be the way to go. > > That's just my two cents though, and I'm willing to help clear out the > current issues no matter which way it goes. >
I agree, however, should an update be backward compatible or not? I mean, is it reasonable for someone to update their Test::Kwalitee module and then have them rewrite their tests such that they skip all tests that require a tar ball of their package etc? These are hard-coded to be skipped in the current version of Test::Kwalitee. This was one of the reasons I also hardcoded some metrics to be skipped. I´m pretty new to writing modules and tests, so I´m at your mercy with regards to best practices, but I too think that Test::Kwalitee should be able to test all metrics and it should be left to the user to decide which, if any metrics should be skipped. This could be easily changed in my existing patch to the current Test::Kwalitee module. It would have the ame behaviour as the current version for skipping metrics i.e.: Test::Kwalitee->import( tests => [ qw( -has_test_pod -has_test_pod_coverage ) ] ) On my return from holiday, who am I best sending my changes to? Nathan
