I'm running test on PHPUnit using Xdebug for generating coverage and it is very slow.
I tried using PHPdbg but that leads to memory errors.
I was told that I can create a filter file, and that should help. Can anyone explain to me how that would work.
The documentation for PHPUnit has information on speeding up code coverage with Xdebug. For more background information I recommend this article.
That being said, I recommend having a look at PCOV for even faster code coverage data collection for PHP and PHPUnit.
Related
Currently we have written some unit test for our php laravel 5.5 application using codeception. just for additional info, our laravel code base have around 200k LOC. For normal unit test run, we noticed that it is really fast in which we can get more than 200 tests to finish within 1 hour.
But the main issue is that when we enabled codecoverage in codeception which is using xdebug by default, we noticed the execution time increased drastically.
Now it already took 1 week but the whole codecoverage execution not even finished yet.
I am not sure whether this is the problem from codeception or xdebug itself but if anybody have experiences running php codecoverage on a huge codebase, it would be nice if you can share how you achieve it. Would appreciate it also if somebody can suggest any other tools to look into. Currently we are considering switching to phpunit but are still open to other tools to explore.
Replacing Codeception with PHPUnit will be a lot of work for little gain, because Codeception uses PHPUnit and its PHP-Code-Coverage library under the hood.
There is a new code coverage extension, called pcov which is supposedly much faster than xdebug.
https://github.com/krakjoe/pcov/blob/develop/INSTALL.md
I haven't tried to use it, but be aware that it requires PHPUnit 8, which is only available on PHP 7.2 or later versions.
Recently I have seen code coverage sped up by replacing xdebug with phpdbg - I can't give exact numbers as the code base has extensive functional tests in its test run (and the speed-up was only for unit tests), but a 2+ hour test and coverage run has been reduced to around 50 minutes.
Note that xdebug and phpdbg can differ in their code coverage (it looked like xdebug better dealt with opcache optimisations).
edit:
Since replacing xdebug with phpdbg, I have seen further speed improvements by replacing phpdbg with pcov.
I have the latest PHPUnit as a phar, placed in /usr/local/bin/phpunit (4.1.3). When I execute this file on my vagrant host (ubuntu 12.04, php 5.3.10), it takes what seems to be 30s to 60s before it actually starts performing the unit tests. I cannot figure out why.
Any ideas?
I ran into a similar problem when running phars in production (AWS's phar. Unfortunately, PHP doesn't do any caching around phar archives, even when using APC as an OpCode cache. So, on each request, PHP is unarchiving and parsing the entire phar. My workaround has been to avoid phars in production unless the archive is small.
If you have the option to upgrade PHP 5.5 w/ OpCode caching, you shouldn't have this problem.
I am going to close this for now as I believe the primary issue is that I am working with a shared folder, and I cannot update to 5.5 like monte suggested. I appreciate your response! I will just have to deal with it for now. If I get a moment I will try a vagrant with 5.5 and OpCode like you suggested, and just run phpunit to see if it is faster, even in a shared folder. If so, I will change my accepted answer.
I'm currently trying to level up on my PHP debugging skills and as part of that I'm trying to learn several new tools. One of them is inclued.
The extension seemingly works fine (no startup error, shows up in phpinfo, generates dump files), but it always reports number of includes as 0, so something is clearly not working right.
At first I suspected this was related to my heavy use of auto_include, but after doing some tests which do not, I doubt that is related.
Class graphs are generated OK, but include maps simply don't exist. Am I simply Doing It Wrong, or is the extension broken? I just don't know and even after some heavy duty googling cannot find anything useful.
I installed inclued using the "phpize method". My PHP version is 5.3.2 running on Mac OSX 10.6.5. I also have XDebug and memtrack installed.
After doing a test run with valgrind watching Apache I noticed xdebug was operating below inclued. On a blind test I tried disabling XDebug and lo and behold: inclued works as expected.
So to answer my own question:
Don't use XDebug in conjunction with inclued if you want to have include graphs. Class graphing works fine with XDebug running.
I'm currently using Zend Framework in conjunction with PHPUnit to conduct unit testing on an application. When Hudson executes the PHPUnit shell command, the maximum PHP memory limit is reached sometime during code coverage generation. I currently have a total of 41 tests with 334 assertions.
I have successfully eliminated this error by raising the memory_limit setting to 768M using the -d memory_limit=768M switch; however, I am worried that as the complexity increases along with the total number of tests/assertions, I will not have enough memory to generate the HTML for code coverage statistics.
OS: CentOS 5.5
Control Panel: WHM/cPanel
CI Server: Hudson
/usr/local/bin/phpunit
--verbose
-d memory_limit=512M
--log-junit ../../build/logs/phpunit.xml
--coverage-clover ../../build/logs/coverage/clover.xml
--coverage-html ../../build/logs/coverage-html/
Fatal error: Allowed memory size of
536870912 bytes exhausted
Before committing my changes and letting Hudson handle the rest, I use Windows 7 for development. The memory usage never exceeded 340MB while running the same command within W7.
By reducing the number of files included within code coverage, as well as increasing the overall memory limit in PHP, I was able to basically kill this error. The entire Zend Framework was being included within code coverage, which is very large.
Do you have xdebug profiling enabled, if so try disabling it. I've experienced this problem before, and it came down to extensions in php (specifically xdebug profiling and/or Inclued heirarchy viewer)
As of 2019, you can use the PCOV driver with PHPUnit to generate your code coverage report. In my experience, it's only marginally less performant than running a plain PHPUnit suite.
Read Speed up PHPUnit Code Coverage Analysis for some good benchmark comparing XDebug, PHPDebug and PCOV. It also has instructions on how to enable PCOV on PHPUnit 8.
Read Setup PHP PCOV for 5 times faster PHPUnit code coverage for instructions on setting up PCOV on PHPUnit7 and below.
I've been working on writing unit tests for my PHP code. PHPUnit is what I'm using for this.
I have some classes that work great until...
I throw XDebug into the mix.
At that point, PHPUnit doesn't crash or anything, but setExpectedException never triggers.
In fact, the code never goes beyond that point.
Anyone run across this and know what the solution is?
Edit: This is with the PHP5.2.6, Latest versions of XUnit and XDebug. This is on linux fedora 7
I've had some problems before with one combination of Xdebug & PHPUnit (as did others, from a report I say on devzone.zend.com at the time), but that was a while ago. PHPUnit does explicitly support Xdebug though - and I'm using it to produce code coverage reports for my own systems.
I'd suggest the fairly standard debugging techniques, updating any versions you can (maybe even PHP?) commenting out the #setExpectedException, or throwing it explicitly - and of course, making sure that you have full warnings and errors being shown with error_reporting(E_ALL|E_STRICT); set on.
Don't forget to stop and restart the Apache server to make sure that the Xdebug module is loaded as well.