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

Hello ! Greg Beaver wrote:

Stephan Schmidt wrote:

There are times, when the service is responding with in internal server error due to a very high load. How should unit tests cope with that.

Mock objects can be used to easily simulate any input that the thing can provide - as long as it is designed to allow plugging them in. For examples, see the unit tests for PEAR - they literally simulate PEARweb as well as downloading files, so that error conditions can be tested as well. But having said this...

While I agree, that unit tests are a good thing, they are not suited for every package. We have rules, that they should be included in stable releases, but how do you test against a moving target. The tests are supposed to test the package, but it would be more like testing whether the service still responds the same way it did yesterday.

... I agree - as long as a package remains alpha or less stable, unit tests don't make much sense. When things calm down, they become feasible - it's an incredible amount of work to do tests, but much more to *re-do* tests.

For integration tests, application as a whole, what should come after unit tests of each public interfaces of packages, you need often to "simulate" a lot of different stuff as: - environment and server variables - dynamic responses of external services (URL...) - stored data as needed before the test. For the last you can proceed with backups. The 2 firsts of them can be simulated as you mention. Just it's a hard work to encode all the data and events you require for often several test cases. Oher point is such "mock" pluggin should not alter the behaviour of object. It should be feasable to have some learning integration tester, which could on request, store all or part of environment and server variables and then be able of reproduce them later and again. (it's partly related to my Console_Extend proposal: http://pear.php.net/pepr/pepr-proposal-show.php?id=170) For URL services, it could be done having an intermediate local learning URL which would do the real link but storing the response so to reproduce it too. 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. IMO if writing the test costs the same as writing the code, just few developers do it fully. So it's a real need to have some facilities to encode the tests. Bye. bertrand Gugger (toggg)