Phpunit: 7.2.5 breaks BC !

Created on 21 Jun 2018 · 4Comments · Source: sebastianbergmann/phpunit

| Q | A
| --------------------| ---------------
| PHPUnit version | 7.2.5
| PHP version | 7.1, for example
| Installation Method | Composer, but doesn't matter

newly released 7.2.5 breaks BC:
https://github.com/sebastianbergmann/phpunit/commit/bcb4c788c7872cd2f885ccf50285f6feb7cfff1a#diff-9ae7a972d07df5f73629d5d315bf405aR521

formal declaration of method changed:

-    public static function assertNotEquals($expected, $actual, string $message = '', $delta = 0.0, $maxDepth = 10, $canonicalize = false, $ignoreCase = false): void
+    public static function assertNotEquals($expected, $actual, string $message = '', float $delta = 0.0, int $maxDepth = 10, bool $canonicalize = false, bool $ignoreCase = false): void

for that, my integration crashes on incompatible method headers:
https://travis-ci.org/FriendsOfPHP/PHP-CS-Fixer/jobs/394945074#L655

PHP Fatal error:  Uncaught Declaration of
PHPUnitGoodPractices\Traits\IdentityOverEqualityTrait::assertNotEquals($expected, $actual, string $message = '', $delta = 0, $maxDepth = 10, $canonicalize = false, $ignoreCase = false): void
should be compatible with
PHPUnit\Framework\Assert::assertNotEquals($expected, $actual, string $message = '', float $delta = 0, int $maxDepth = 10, bool $canonicalize = false, bool $ignoreCase = false): void

Source

keradus

Most helpful comment

I shall make them final in PHPUnit 8 then :-)

sebastianbergmann on 21 Jun 2018

👍4

All 4 comments

Why do people overwrite PHPUnit's assertions? sigh

sebastianbergmann on 21 Jun 2018

short story? because they are not marked as final

long story? vide https://github.com/PHPUnitGoodPractices/Traits/blob/master/src/IdentityOverEqualityTrait.php#L46-L56 for my concrete case

keradus on 21 Jun 2018

I shall make them final in PHPUnit 8 then :-)

sebastianbergmann on 21 Jun 2018

👍4

Then, can we first bring from dead topic of registering assertions/expectations? So one can decide to have some extra assertions available globally (without manual import in every single test) or not register all built-in ones ?
But in general, :+1: for final methods/classes/exposing interfaces over concrete implementations

Also, let me request this once more ;) please, let us start using @internal tag for things out of BC promise, that shall not be use out of this library.
(Eg, I can prepare PR that would make everything marked internal, and then we would open what shall be public)

keradus on 21 Jun 2018

Was this page helpful?

0 / 5 - 0 ratings