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

<pear-sys@php.net> wrote : > > Greg Beaver (http://pear.php.net/user/cellog) has commented on the proposal > for RFC::How the QA Team will work.. > > Comment: > > A serious omission from this RFC involves regression testing. > > The QA team should actively enforce regression testing in a format that is > both easy to use and easy to set up. > > This means that either PHPUnit, PHPUnit2, or Simpletest should be recommended > for object-based code, and run-tests should be recommended for code that can > only be run from the global context. The only example I can think of that > requires global context is code that relies upon the output of > debug_backtrace(), although there may be other examples. > > The QA team should also actively define standard ways to structure regression > tests. > > Regression tests should consist of 2 kinds of test suites > > - API tests > - internal functionality tests. > > The API test suites should consist of bounds checking for every public method > of a class, and testing expected output. These tests should work for every > minor version without modification. > > The internal functionality tests consist of bug-fixing tests, and other > verification of functionality that may break on a minor version release with > the shifting of private functionality. > > Any package that does NOT require external setup to function must have an API > test suite to be considered stable. Packages that require external setup, > such as database or internet connections, should be handled on a case-by-case > basis. > > The pear run-tests command shall be modified to work with PHPUnit/PHPUnit2 > test suites in a future version of PEAR to make it easy to run regression > tests. If we have had to write unit tests before proposing QuickForm, I think QuickForm would never had made it into PEAR. By enforcing tests, PEAR will end up as a "small classes" repository (SPEAR ?). Larger packages will probably go somewhere else where there is more freedom. 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. So I am -1 for enforcing this. End-users have the choice to use packages with unit tests or not. Unit tests don't prove anything, they might be crap as well and it is not because your packége has unit tests that it will be better designed or less buggy. Bertrand Mansion Mamasam