> I'm strongly in favor of tests being in the same package as the thing being testing
Me too - but that's not what this is. 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? On Tue, Dec 11, 2018 at 3:42 PM Sara Golemon <p...@golemon.com> wrote: > On Friday, December 7, 2018 at 10:19:46 AM UTC-6, Rasmus Schultz wrote: >> >> How is this in any way acceptable? >> > > I'm strongly in favor of tests being in the same package as the thing > being testing, and CI runs against that being part of the commit process, > so in THAT one way I'd call it "acceptable". > However, I absolutely see your point about tying it to a specific testing > framework, even if that framework is the de facto standard for composer > based PHP projects. > > Would you be less bothered by this if it were driven by PHP's own > run-tests.php ? That would give us reliable testing without any > framework-favoring dependencies (depending on PHP is an avoidable given, > after all). > > >> I'm calling for a bugfix release to remove these ASAP. >> >> I disagree with the urgency. Yes it's bad, and yes we should address > fixing it, but nothing is broken *right now*, so we don't need to rush into > it. > > -Sara > > -- > You received this message because you are subscribed to a topic in the > Google Groups "PHP Framework Interoperability Group" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/php-fig/DsmK600GAas/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > php-fig+unsubscr...@googlegroups.com. > To post to this group, send email to php-fig@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/php-fig/a81c3c57-d084-4e47-a7ba-799af33d0ee5%40googlegroups.com > <https://groups.google.com/d/msgid/php-fig/a81c3c57-d084-4e47-a7ba-799af33d0ee5%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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 php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CADqTB_gQHi0%3Dsz6oTBBiDw1u34f5S2KktnVVLm3QCudViUKCBg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
