Hi!
That's easy to say - but how exactly you're going to test
functionality of, say. ext/intl without testing the underlying ICU
library?
Well, here's the way I see it:
Extensions (including ext/intl) declare their API and tests are made
againt this API. No more and no less.
It's all sounds very nice in theory, except that in practice it
doesn't work this way. Different versions of the library return
different data, different errors, have different conditions, etc. You
can just declare half of the tests to be "not API", but in fact
it is, that's what people use and that's what they want to be sure that
it works - just different versions of it act differently.
If, for example, some error-text comes directly from underlying
library and extension doesn't have control over it it shouldn't be
part of API. In this case we can test that "some error-text was
returned" but we shouldn't test for exact text-match
How do you know that "some text" is the error and that it's the correct
one and not just generic "wrong library call" one which is produced on
any bad call?
And you can't just declare that number formatting routine returns "some
text" - it would be useless. You want very specific text. But what if
some detail of that text changes for some of the test cases?
--
Stanislav Malyshev, Zend Software Architect
s...@zend.com http://www.zend.com/
(408)253-8829 MSN: s...@zend.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
