Re: Tests repository
| From: | Eric Stewart | Date: | Fri, 12 Mar 2010 22:13:41 +0000 |
| Subject: | Re: Tests repository | ||
| References: | 1 2 3 4 5 6 7 8 9 10 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-47193@lists.php.net to get a copy of this message | ||
On Fri, Mar 12, 2010 at 4:55 PM, Stanislav Malyshev <stas@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
> stas@zend.com http://www.zend.com/
> (408)253-8829 MSN: stas@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