Re: [PEPr] Comment on RFC::How the QA Team will work.

Bertrand Mansion wrote:

<pear-sys@php.net> wrote :

I said this

Any package that does NOT require external setup to function must have an API test suite to be considered stable.

and this Packages that require external setup,

such as database or internet connections, should be handled on a case-by-case basis.

NOT this

If we have had to write unit tests before proposing QuickForm

This next argument is the same straw man argument used against requiring documentation.

PEAR will end up as a "small classes" repository (SPEAR ?). Larger packages will probably go somewhere else where there is more freedom.

This next statement is in direct contradiction with "packages that require external setup, such as database or internet connections, should be handled on a case-by-case basis"

Furthermore, using unit tests might be good for you but they might not be adapted to everyone or to every packages. It is a coding method, personally I use something else.

What method do you use to regression test? Larger projects outside of PEAR have no trouble writing unit tests, look at WACT. In addition, it is no more difficult to unit test than it is to write documentation, which both you and Alexey have shown great ability to do for HTML_Quickform. I know it is hard to write unit tests for a large pre-existing package, I've been writing them for phpDocumentor and PHP_Parser. I think everyone would be willing to see incremental additions of unit testing to each release for large pre-existing projects that would be delayed months by unit testing requirements. In the past, I used "something else" to regression test, and the number of bugs simply increases. Packages I have unit tested where others can run the tests have displayed fewer bugs, and the bugs stay fixed after I write a test for them. I happen to dislike some of the problems with PHPUnit 1.x and with run-tests.php, and this is one reason I specifically don't want to rely on any 1 testing framework. I would like to develop an interface to pear run-tests that will work with all the viable alternatives and provide an interface to others, to make this easier. One of the two serious problems that QA has been formed to deal with are BC breaks/broken releases. API unit tests will kill this one cold, and need not be complex. The verification that method parameters/names haven't changed from release to release is a crucial part of the release process, and would be a lot simpler with both interfaces and unit tests for the interfaces. The other issue is orphaned packages and is not relevant. Greg