Michael Gauthier [2008-12-30 19:11 UTC] I think these are all great best practices and this should be included in the PEAR manual under "testing". A section on how to make your tests easily integrate with the PEAR CI server would save lots of headaches.
I'm hesitant to require all of these points for new packages, as it would likely turn contributors away. The amount of work required to write comprehensive unit tests is sometimes more work than writing the package in the first place. For example, Crypt_GPG's tests are a thousands of lines longer (excluding comments) than the library code itself.
I think requiring the conventions in 8, 11, 12 and 13 makes sense as they're things that make it easier to write tests, but don't involve actually writing tests. This would make it easier for the QA team to build or improve tests for packages.
Matthew Weier O'Phinney [2008-12-30 21:06 UTC] I disagree with Michael; I think if a contributor is serious about releasing their package, they need to test it. They owe it to their users and those who may maintain it later. Testing code shows that the code does what it is expected to do. As a user, this is critical -- it not only helps assure quality, but also serves as a "manual" of how to use the component should the documentation be unclear.
+1 from me.
Bill Shupp [2008-12-30 21:56 UTC] I tend to agree with Matthew. New contributors can seek help with testing on the mailing list before proposing the package if they need it.
Daniel O'Connor [2008-12-30 22:09 UTC] Just to point out, only number 1 - have at least some unit tests with your proposal - would be the hurdle for new contributors.
As they improve on their code and get near a 1.0.0 release, the intent is they are able to tick off the rest over time.
Christian Weiske [2009-06-25 08:07 UTC] Is this proposal dead, or are you going to finish it?
|
