On Tue, Dec 11, 2018 at 12:14 PM Hari K T <[email protected]> wrote:
> Hi all, > > >> The package consists of interfaces - so there's nothing really to test, >> and there's no CI or anything like that set up. (and it wouldn't work if >> there were, because there's no dependency on PHPUnit although it's >> extending that class.) >> >> This test is for implementations - so these are literally tests for other >> packages. >> >> So yes, I'm entirely in favor of these tests residing in those packages - >> or a utility package, if the tests happen to be useful to other packages. >> (I'd go as far as naming that package with "phpunit" in the name, since >> these facilities aren't generic utilities - they're specific to phpunit, >> and the base-class depends on it.) >> >> > nothing is broken *right now*, so we don't need to rush into it >> >> I disagree - the damage is accumulating as people start to build things >> that depend on these facilities. >> >> At the very least, an immediate bugfix release with deprecations should >> be released, so that people get informed of the mistake before the problem >> gets worse. >> >> A mistake was made, and it's important to at least inform of that fact as >> quickly as possible - whether we do or don't actually remove it down the >> line at a later time... well, I'm not fond of things that light up red in >> my IDE because of undefined classes, but lets at least deprecate so people >> know it was a mistake? >> > > I have been going through this thread and I want to agree with Rasmus > here. > > As php-fig is making interfaces there is no need for test packages. And if > needed this can be a util package. Better late than never ? Because things > will get worse with more time being given. > I totally disagree that there is no need for test packages. The specifications for the interfaces are generally quite strict, but, particularly with versions that do not use PHP 7 (for scalar and return type hints), PHP 7.1 (nullable and void types), or PHP 7.2 (object type hint), having a test suite that can verify that the implementation conforms to the specification is quite useful, particularly for consumers who want a guarantee that swapping one implementation for another will result in the same behavior. We've had a number of issues with PSR-7 over this, and the test suite that Tobias Nyholm created helps implementors tremendously in this regard. That said, I tend to agree these should be _separate packages_. I disagree with the urgency, but do agree it should be taken care of sooner rather than later. -- Matthew Weier O'Phinney [email protected] https://mwop.net/ -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAJp_myXiXQCXvYccMyV96oNJO0B_sDChiHnx-Aar%2Be71QSD7rQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
