This morning I tried to run some unit tests, and to my surprise it failed with an error that PHPUnit 3.7.0 is now required. This was apparently done in Gerrit change 105920[1] in response to bug 59759.[2]
Grepping through 1.23wmf10 finds the PHPUnit function complained about in that bug in only a few extensions (Diff, EducationProgram, DataTypes). I ran unit tests against various extensions that I have locally installed, and core, AntiSpoof, cldr, FlaggedRevs, Gadgets, GeoData, Math, OAuth, ParserFunctions, Scribunto, and TitleBlacklist all appear to work fine in 3.6.10. TemplateData uses another 3.7-only function (assertJsonStringEqualsJsonString), which is also used in one test in EventLogging.
The problem here is that Ubuntu's upcoming 14.04 Trusty Tahr, as well as Debian unstable (sid), currently contain PHPUnit 3.6.10.[3][4] It seems to me that requiring our developers to manually install a different version of phpunit is instead going to make it even less likely for developers to write or run tests, and will make it that much more difficult to fix tests if they break.
Is there anything in 3.7 that we actually need? The problematic functions seem to just be additional asserts that could probably be worked around. Or is there any hope that Debian and/or Ubuntu will upgrade PHPUnit any time soon?[5]
[1]: https://gerrit.wikimedia.org/r/#/c/105920/ [2]: https://bugzilla.wikimedia.org/show_bug.cgi?id=59759 [3]: http://packages.debian.org/phpunit [4]: http://packages.ubuntu.com/phpunit [5]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=697343
On Tue, Jan 14, 2014 at 7:58 AM, Brad Jorsch (Anomie) <bjorsch@wikimedia.org
wrote:
The problem here is that Ubuntu's upcoming 14.04 Trusty Tahr, as well as Debian unstable (sid), currently contain PHPUnit 3.6.10.[3][4] It seems to me that requiring our developers to manually install a different version of phpunit is instead going to make it even less likely for developers to write or run tests, and will make it that much more difficult to fix tests if they break.
Is there anything in 3.7 that we actually need? The problematic functions seem to just be additional asserts that could probably be worked around. Or is there any hope that Debian and/or Ubuntu will upgrade PHPUnit any time soon?[5]
What version is available via PEAR? Installing via that is no more manual than apt.
-Chad
On Tue, Jan 14, 2014 at 11:07 AM, Chad innocentkiller@gmail.com wrote:
What version is available via PEAR? Installing via that is no more manual than apt.
Also don't forget composer as well.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science
Hey,
What version is available via PEAR? Installing via that is no more
manual than apt.
Sebastian recommends that you use the phar, which is a lot easier then PEAR. Instructions on how to use it can be found at:
https://github.com/sebastianbergmann/phpunit#installation
This morning I tried to run some unit tests, and to my surprise it failed
with an error that PHPUnit 3.7.0 is now required.
For Diff this has been required for close to a year I think.
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 --
On Tue, Jan 14, 2014 at 8:21 AM, Jeroen De Dauw jeroendedauw@gmail.comwrote:
Hey,
What version is available via PEAR? Installing via that is no more
manual than apt.
Sebastian recommends that you use the phar, which is a lot easier then PEAR. Instructions on how to use it can be found at:
Can we use the phar in core? Since we construct our own PHPUnit environment and don't run the standard PHPUnit binary...can you use a phar file for loading a library and not just executing a script?
-Chad
Hey,
can you use a phar file for loading a library and not just executing a
script?
Yeah, you can include the phar (with a PHP include statement).
Can we use the phar in core?
Sure. One reason I've seen brought forward to bundle such a phar with a project is that then everyone runs the same version of PHPUnit.
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 --
On Tue, Jan 14, 2014 at 8:39 AM, Jeroen De Dauw jeroendedauw@gmail.comwrote:
Hey,
can you use a phar file for loading a library and not just executing a
script?
Yeah, you can include the phar (with a PHP include statement).
Can we use the phar in core?
Sure. One reason I've seen brought forward to bundle such a phar with a project is that then everyone runs the same version of PHPUnit.
Well, we shouldn't bundle it, but it'd be nice to use it if you've got it, rather than having PHPUnit installed in your include_path
Something like:
`php phpunit.php --phar=/foo/bar/phpunit.phar`
would be fantastic imho.
-Chad
On Tue, Jan 14, 2014 at 11:07 AM, Chad innocentkiller@gmail.com wrote:
What version is available via PEAR? Installing via that is no more manual than apt.
Err, yes it is. With apt it gets upgraded whenever I upgrade anything else, while pear is in its own little world with its own dependencies and such.
pear, pecl, cpan, npm, and the rest of those language-specific package managers seem like a very poor substitute to me.
On Tue, Jan 14, 2014 at 11:07 AM, Chad innocentkiller@gmail.com wrote:
What version is available via PEAR?
On Tue, Jan 14, 2014 at 11:13 AM, Tyler Romeo tylerromeo@gmail.com wrote:
Also don't forget composer as well.
On Tue, Jan 14, 2014 at 11:21 AM, Jeroen De Dauw jeroendedauw@gmail.comwrote:
Sebastian recommends that you use the phar
All the more reason to use none of the above.
On Tue, Jan 14, 2014 at 9:31 AM, Brad Jorsch (Anomie) <bjorsch@wikimedia.org
wrote:
On Tue, Jan 14, 2014 at 11:07 AM, Chad innocentkiller@gmail.com wrote:
What version is available via PEAR? Installing via that is no more manual than apt.
Err, yes it is. With apt it gets upgraded whenever I upgrade anything else, while pear is in its own little world with its own dependencies and such.
pear, pecl, cpan, npm, and the rest of those language-specific package managers seem like a very poor substitute to me.
Fair enough. I just realized what a hypocrite I was being :)
I do like the idea of letting you specify the phar from the command line though, so you don't have to worry about include_paths or can swap out different versions at runtime.
-Chad
On Jan 14, 2014 11:58 AM, "Brad Jorsch (Anomie)" bjorsch@wikimedia.org wrote:
This morning I tried to run some unit tests, and to my surprise it failed with an error that PHPUnit 3.7.0 is now required. This was apparently done in Gerrit change 105920[1] in response to bug 59759.[2]
Grepping through 1.23wmf10 finds the PHPUnit function complained about in that bug in only a few extensions (Diff, EducationProgram, DataTypes). I ran unit tests against various extensions that I have locally installed, and core, AntiSpoof, cldr, FlaggedRevs, Gadgets, GeoData, Math, OAuth, ParserFunctions, Scribunto, and TitleBlacklist all appear to work fine in 3.6.10. TemplateData uses another 3.7-only function (assertJsonStringEqualsJsonString), which is also used in one test in EventLogging.
The problem here is that Ubuntu's upcoming 14.04 Trusty Tahr, as well as Debian unstable (sid), currently contain PHPUnit 3.6.10.[3][4] It seems to me that requiring our developers to manually install a different version
of
phpunit is instead going to make it even less likely for developers to write or run tests, and will make it that much more difficult to fix tests if they break.
Is there anything in 3.7 that we actually need? The problematic functions seem to just be additional asserts that could probably be worked around.
Or
is there any hope that Debian and/or Ubuntu will upgrade PHPUnit any time soon?[5]
-- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Ive been manually commenting out the version check for a little while now when i run them locally.
-bawolff
"Brad Jorsch (Anomie)" bjorsch@wikimedia.org wrote:
[...]
The problem here is that Ubuntu's upcoming 14.04 Trusty Tahr, as well as Debian unstable (sid), currently contain PHPUnit 3.6.10.[3][4] It seems to me that requiring our developers to manually install a different version of phpunit is instead going to make it even less likely for developers to write or run tests, and will make it that much more difficult to fix tests if they break.
[...]
+1. This has been a problem in the past as well, and it's especially frustrating to see that ancient browsers or com- ponents no longer supported upstream receive attention, while for a central development tool manual intervention is needed for essentially syntactic sugar.
Tim
wikitech-l@lists.wikimedia.org