[dev] Preparing compatibility with PHPUnit 6

[Ralf Lang]

Hi Mike,

Am 06.06.20 um 23:25 schrieb Mike Gabriel:
> Hi Ralf, hi all,
>
> picking up a thread from 2018...
>
> On  Do 07 Jun 2018 08:59:22 CEST, Ralf Lang wrote:
>
>> Am 27.05.2018 um 15:01 schrieb Jan Schneider:
>>>
>>> Zitat von Ralf Lang <lang at b1-systems.de>:
>>>
>>>> Am 15.05.2018 um 22:50 schrieb Jan Schneider:
>>>>>
>>>>> Zitat von Ralf Lang <lang at b1-systems.de>:
>>>>>
>>>>>> Am 15.05.2018 um 15:29 schrieb Andy Dorman:
>>>>>>> On 5/15/18 8:20 AM, Mathieu Parent wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> In Debian (and Ubuntu), we need to patch Horde to pass tests with
>>>>>>>> latest phpunit. This leads to divergence with Horde that we
>>>>>>>> want to
>>>>>>>> avoid.
>>>>>>>>
>>>>>>>> I propose to send pull requests to do the following, preserving
>>>>>>>> current compatibility with phpunit 4.8 while preparing for
>>>>>>>> phpunit 6:
>>>>>>>> - 1. Add expectException method to Horde_Test_Case calling
>>>>>>>> parent::expectException on phpunit >= 5.2 and
>>>>>>>> setExpectedException on
>>>>>>>> < 5.2 (see [PHPUnit-5.2.0])
>>>>>>>> - 2. Replace all "extends PHPUnit_Framework_TestCase" by "extends
>>>>>>>> Horde_Test_Case" (> 300 occurences)
>>>>>>>> - 3. Replace all "$this->setExpectedException(...)" calls by
>>>>>>>> "$this->expectException(...)" (this will require a version bump of
>>>>>>>> dependency Horde_Test to the one implementing 1.)
>>>>>>>>
>>>>>>>> This will fix most of the compatibility problems.
>>>>>>>>
>>>>>>>> What do you think? Maybe step 2 can be done by one of the core
>>>>>>>> devs
>>>>>>>> with direct commit rights?
>>>>>>>>
>>>>>>>> Regards
>>>>>>>>
>>>>>>>
>>>>>>> FWIW, we use debian and I concur.
>>>>>>>
>>>>>>
>>>>>> That's the kind of refactoring I'd like to test my understanding of
>>>>>> Horde_Refactor with ... but no time before openSUSE Con end of
>>>>>> may...
>>>>>>
>>>>>> Also jan should comment as the test framework is a sensitive part...
>>>>>
>>>>> Sounds like a good plan. And the refactoring should be possible
>>>>> with a
>>>>>  more or less simple search-and-replace.
>>>>>
>>>> I read this as a go-ahead for after openSUSE con this weekend?
>>>> Would you
>>>> prefer a series of PRs against the individual repos or direct commits
>>>> (in those repos where I have access)?
>>>> Would you like a changelog entry/metadata update with this change?
>>>
>>> This is BC with PHPUnit 4 that we currently ship with Horde_Test,
>>> right? Then I don't see a changelog being necessary.
>>>
>>> Better than a huge number of patches would be a small script to do
>>> the actual changes. The commits can be done by one of us with full
>>> commit access, all at once.
>>>
>>
>> For 1) I am still figuring... current PHPUnit has
>> PHPUnit\Runner\Version::id for version checking. I need to look if
>> Version 4 also has it.
>> I hope the mass edit scripts for 2 and 3 will be ready by tonight.
>
> I am currently looking into Horde Unit Tests and they all make severe
> problem as time has passed and PHPUnit has moved on to version 8.5.2
> in Debian unstable.
>
> I understand that PHPUnit is a fast moving target, but bundling an old
> PHPUnit version in Horde_Test is neither an option for Debian.
>
> There are several options at hand:
>
>   * pick up PHPUnit test migration, but not to 6, but 8.
>   * bundle PHPunit 4.8 in php-horde-test in Debian as upstream does
>   * don't run Debian's autopkgtests on php-horde-* packages
>
> I guess this original idea of a script that walks over all packages
> and updates the test API would be a good idea. However, is keeping
> compatibilities with PHPUnit 4.8 really a good approach considering
> that we have moved on much further with PHPUnit these days?
>
> Currently, the php-horde* packages won't migrate to Debian testing,
> because of failing unit tests after upload. Any suggestions from
> people involved upstream?
>
My current suggestion would be: Drop the unit tests from the deb/rpm
delivery. It is a blocker and most likely the users of unit tests
through deb packages are very few.

Horde 5 is spreading very hard, supporting very old PHP 5.3 for most of
the main apps and libs, keeping compat with pear while many pear
channels are dead, pirum is dead and pear.php.net is a mess - which is
why things like SabreDav are bundled rather than just required and used.

There will be a lot of challenges when horde switches to composer. I'd
rather save spare time for that.


-- 
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: lang at b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 2688 bytes
Desc: not available
URL: <https://lists.horde.org/archives/dev/attachments/20200915/73732fd4/attachment.key>