Last modified: 2012-04-16 09:15:35 UTC
Created attachment 7925 [details] Starting patch Per discussion on IRC with ^demon. Apparently PHPUnit does not work well with globals, and lime does that better. I've written a wrapper for lime, as well converted a few unit tests for the GlobalFunctions.php file from the PHPUnit suite, and attached it.
Adding ^demon, as he is a major participant.
For the lime ignorant among us, could you post a URL where we can find more info Oh, nevermind, it looks like we're on a Symfony kick. From the header of lime.php: /** * This file is part of the symfony package. Adding Trevor to see what he thinks about PHPUnit and globals (Yes, I know they can be a pain.)
It's more of a tracking thing than a bug. My problem with PHPUnit isn't with globals, but because it _doesn't work_. I've worked for countless hours trying to get the PEAR packages working, configuring me setup to use the proper include path, and all sorts of other hacks, and none of them have worked. lime, on the other hand, is native PHP code, so no more PEAR, and it's rediculously easy to use. But that's just me. Even though sf/zf/cake may be hated around here, much of the stuff they make is quite good. This is a feature I'd like to see far more than sfFinder, which was reverted.
If you need help getting PHPUnit working, ask in IRC. I'll be there Monday, Dec 27 as "hexmode". Helpful information would be your OS and PHP version. I apologize for the doubting the statement "it _doesn't work_" but several people have gotten it to work and we do depend on it daily. That said, I think part of the resistance to other frameworks (I personally don't "hate" them and have found cake, for example, useful for some of my projects) is that MediaWiki is an almost 10-year-old framework in its own right even though it does not sell itself as one.
Henc(In reply to comment #4) > I > apologize for the doubting the statement "it _doesn't work_" but several people > have gotten it to work and we do depend on it daily. > Hence the "my problem". > That said, I think part of the resistance to other frameworks (I personally > don't "hate" them and have found cake, for example, useful for some of my > projects) is that MediaWiki is an almost 10-year-old framework in its own right > even though it does not sell itself as one. I can see the need for some resistance, but it becomes too much resistance when people start becoming irrational when the names are even mentioned in casual conversation. Just my 2¢. Now back to the previously scheduled bug...
> Now back to the previously scheduled bug... But this isn't a bug, it is "your problem" (essentially your words) that you need help solving. Instead of solving the problem that you're having with PHPUnit, you propose that we use Symfony's testing framework which (hypothetically) fixes a problem. You haven't verified (at least to my knowledge) that the problem ^demon describes is, in fact, non-existent in lime. For what its worth, we're already using PHPUnderControl's PHPUnit integration. How does lime work with that? I hate to say it, but this sounds very much like WONTFIX.
> But this isn't a bug, it is "your problem" (essentially your words) that you > need help solving. My problem isn't why ^demon and I are working on this, but it does provide an example of why PHPUnit isn't always the best solution. > You haven't verified (at least to my > knowledge) that the problem ^demon describes is, in fact, non-existent in lime. lime works in the global scope. Problem solved. > For what its worth, we're already using PHPUnderControl's PHPUnit integration. > How does lime work with that? I don't know exactly how PHPUnderControl works, but I do know lime can output in PHPUnit-compatible XML files. > I hate to say it, but this sounds very much like WONTFIX. This isn't a bug. It's to keep track of progress on the project. It's mainly a placeholder. Bugzilla isn't only for bugs. Basically, what I'm trying to say here is that I'm thinking of one thing, and you're thinking of another. You're thinking we're trying to replace it because I can't get PHPUnit to work (which is false, I assure you). I'm thinking we're trying to change certain tests (not all of them, I assure you) due to a global scope issue. I would advise you to hold off on jumping to conclusions (and WONTFIXing) until something comes out of this. ^demon's vacationing for a few days, so I'm hoping that he can explain this situation better.
I'm not marking this WONTFIX because it is possible I'm wrong and lime is the right solution to the global scope problem. Which is why I've asked Trevor to weigh in. He has a bit more knowledge of PHPUnit than I do. Maybe he will say that the problem with globals that ^demon describes can't actually be fixed with PHPUnit. Maybe we will find that lime can do something that PHPUnit should not.
(In reply to comment #6) > For what its worth, we're already using PHPUnderControl's PHPUnit integration. > How does lime work with that? Yes the WMF is currently running a testing setup, but this bug is about creating a testing setup that works with Mediawiki in general so what WMF is running is quite frankly irrelevant, unless I've missed somewhere in this bug where it is a request to setup it up at WMF. If users want to setup a testing framework with tests and maintain, they can go ahead and do it (In reply to comment #8) > I'm not marking this WONTFIX because it is possible I'm wrong and lime is the > right solution to the global scope problem. > > Which is why I've asked Trevor to weigh in. He has a bit more knowledge of > PHPUnit than I do. Maybe he will say that the problem with globals that ^demon > describes can't actually be fixed with PHPUnit. Maybe we will find that lime > can do something that PHPUnit should not. This bug is about creating a testing framework with lime and not disucssing a issue with phpunit, so I kinda can't see why you be WONTFIXing it.
I have lots of thoughts on the issue. I'm rather frustrated with PHPUnit, and I think lime might solve some of my headaches (not claiming they'll solve yours) Using lime is not the same as using Symfony or Zend, its a self-contained unit test thingie. And its not nearly as bulky as Phpunit. More after Christmas.
> Yes the WMF is currently running a testing setup, but this bug is about creating a testing setup that works with Mediawiki in general so what WMF is running is quite frankly irrelevant I don't pretend to know what the community or even the members of the community who are in the WMF think. I only speak for myself. Still, as one of the developers working to get some sort of testing in place, I don't think it is helpful to have multiple different frameworks in play since it makes automated testing more complicated. The risk of shipping a release with broken tests is higher if we have multiple frameworks to support. In my opinion, additional frameworks shouldn't be included in core simply because one developer cannot get PHPUnit working, which is apparently the only really solid reason being given now. If there are intractable problems with global scope that lime can solve, then that is different, since currently MediaWiki depends very heavily on globals. [I think I should start using "the grinch" as my alias given how much I've posted on this during (and ON) Christmas.)
(In reply to comment #11) > If there are intractable problems with > global scope that lime can solve, then that is different, since currently > MediaWiki depends very heavily on globals. PHPUnit does not work in the global scope. lime does work in the global scope.
> PHPUnit does not work in the global scope. lime does work in the global scope. Ok, but to make a really convincing case, it would help to have an interesting test that works under lime but not PHPUnit. Even a relatively dull test would be better than the back-n-forth here.
I want to make sure of a couple of things: 1. Any serious conversation about introducing Lime as a framework happens on wikitech-l 2. This conversation happens at a time when Trevor is around to weigh in (he's back on January 3, I believe) Before taking this to wikitech-l, I agree with Mark that to have a really convincing case, it would help to show a side-by-side comparison. It would also be helpful to make the case that Lime has *true* potential as an up-and-coming framework. We can't afford to try to be the kingmakers on a test framework that doesn't stand a reasonable chance of becoming a widely-used standard.
It looks like the symfony folks are moving away from lime and toward phpUnit: http://www.symfony-project.org/blog/2010/03/04/symfony-2-0-and-the-php-ecosystem
That is a concern that I raised with ^demon, and he has started to fiddle more with PHPUnit. I wouldn't close this yet, we'll see what comes out of it. Anyway, would it be possible to package PHPUnit completely in MW? If that would be possible, I would be more interested in using PHPUnit. It would avoid PEAR, which is, quite frankly, a poor implementation.
Well, now that we've got PHPUnit not doing destructive tests, I guess that the need for a new framework anyway is reduced. Marking as WONTFIX.
