On Fri, Mar 12, 2010 at 4:55 PM, Stanislav Malyshev <s...@zend.com> wrote:
> 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 > > There are going to be some technical challenges. Some (maybe a lot) of test will need updates or rewriting. run-tests.php may need more improvements than what is already planned. Knowing this, I would still rather update run-tests.php and fix the tests, then continue to applying tests to different branches of the code base. +1 to centralize tests. Eric Lee Stewart