Re: Re: [PEPr] +1 for Web Services::Services_Delicious

bertrand Gugger wrote:

Anyway, even PHPunit could have such learning ability thru some catch points, e.g. in begin of methods. These catch points could store the data as a PHP scritpt. That could ease the writing of unit tests variables'initilization. I suggested that once to Sebastian Bergmann but I mean he was quite busy with a new release in this moment.

I actually wrote a stub for .phpt (pear run-tests) that uses this method to compare all data through var_export() output, instead of using serialize(). It has made unit-testing things like the 16 kb array output of the PEAR_DependencyDB a piece of cake. In addition, since I use Text_Diff, it means that when there is a single line difference in the array, you see: test failure "message" in blah.php line 25 @@267,4 267,4@@

-     'name' => 'fronk',
+     'name' => 'flonk',

but with the simple addition of "$phpunit->showall()" you have a cut-and-pasteable output from var_export(). This may be the answer for PEAR projects in the future, as .phpt provides the easy capability to input complex parameters like $_POST and many, many other things that are not available. Basically, the biggest problem with .phpt in the past is that the --EXPECT-- section must be updated every time there is a change, no matter how small. In addition, it's really hard to put in differences for systems (I had to rewrite the same test twice to put in php4/php5 differences). I've solved this by using the phpunit approach to testing - the only time output is shown at all is when there is an error, and assert* methods are used to do the testing. The only drawback with this method of unit-testing currently is that reporting of errors is not as customizable. This is offset by the fact that no external libraries are needed in order to process the .phpt file format, you can run the test like so: $ php blah.phpt and use eyeballs to see if the test failed or not. In any case, this testing method has made unit-testing extraordinarily simple, because of these key advantages: 1) testing a single method of a test case is not possible in phpunit without modifying the test source file 2) debugging a single method is a piece of cake, and can be done without any external tools 3) a fatal error in a single test will not bring the whole test suite crashing to a halt 4) pear run-tests can be used to verify the validity of a whole directory (or directory tree) of tests 5) the use of var_export() means grabbing expected output is a piece of cake, as the printed output can be cut-and-pasted directly into the php source file. The actual source code is in pear-core/tests/phpt_test.php.inc (.inc because .php is in .cvsignore) Greg