Tag Archives: phpunit

phpunit-speedtrap and WordPress/BuddyPress automated tests

· 1 Reply

One of my personal missions over the last six months has been to shave seconds off of the WordPress and BuddyPress automated test suites. (WP’s tests run in under half the time today than in WP 4.0 – and with the addition of nearly 1000 tests. Score!) One of the tools I use to track down problematic tests is John Kary’s excellent phpunit-speedtrap, which adds a listener to each test run, and produces a report of tests whose running time exceeds a configurable threshhold. phpunit-speedtrap is designed to be used as a Composer dependency, but this is not currently convenient or necessary for the purposes of working with WP/BP (for one thing, I’m the only person doing it). Here’s how I’ve rigged it up to run locally:

  1. Grab a copy of the listener class from Github https://github.com/johnkary/phpunit-speedtrap/blob/master/src/JohnKary/PHPUnit/Listener/SpeedTrapListener.php. I chose to remove the PHP namespacing, but you can do as you wish. Save it somewhere – I put it at ~/.speed-trap-listener.php so that I can use it with all projects.
  2. WP and BP ship with a phpunit.xml.dist config file. The .dist extension means that you can run your own phpunit.xml alongside of phpunit.xml.dist – PHPUnit will prefer the non-dist version if available, while WP and BP’s version control config will ignore it. Copy phpunit.xml.dist to phpunit.xml and add the following block:
    [code language=”xml”]   


    250


         [/code]
    Change the slowThreshold and filepath to whatever you’d like.
  3. Run phpunit. You’ll see something like this:
    Screenshot_2015-03-07_11-50-30

Keep on shavin’!

Disable ext4 barriers for dramatic I/O performance improvement on local machine

· 1 Reply

I was experiencing an issues that made PHPUnit unit tests run increasingly slowly on one of my development machines. The tests that ran the slowest were those that touched the database in some way, which in BuddyPress and WordPress unit tests are most of them. After a bit of poking around, I came across this thread: http://stackoverflow.com/questions/14914467/slow-phpunit-tests. I took the advice of the accepted answer and set barriers=0 in /etc/fstab and it has made a very dramatic difference in PHPUnit execution time: the BuddyPress test suite, for instance, now takes about 30 seconds to run instead of 5-6 minutes.

Making a note of it here for my own future reference. Follow this advice at your own peril – understand the ramifications of disabling barriers before turning them off.

Anthologize automated tests now run using WP’s unit test suite

· Leave a reply

Anthologize, I haven’t forgotten about you! I have some very cool stuff in the works, but for now, a quick update on the progress of the campaign-funded work.

Back in 2011, Patrick Murray-John added some unit tests to Anthologize, covering a number of public methods in the TeiApi class. A number of the major refactoring jobs I’m currently undertaking will require additional test coverage, but they are (unlike TeiApi) dependent on WordPress being initalized. So I’ve migrated Anthologize’s tests to use the WP test suite. I’ve used the scaffold provided by the dope and phatte wp-cli (incidentally, I hope that their scaffold becomes the de facto standard for WP plugin tests).

This change means that, in addition to requiring PHPUnit, you’ll also need to have the WP test suite installed. You can install it manually, but I recommend using wp-cli to get the job done in just a command or two. In brief:


$ wp core init-tests /path/to/wp-tests --dbname=wp_test --dbuser=root --dbpass=asd
$ mysql -u'root' -p'asd' -e 'CREATE DATABASE IF NOT EXISTS wp_test'

To run the tests,


$ cd /path/to/wp/wp-content/plugins/anthologize
$ WP_TESTS_DIR=~/path/to/wp-tests phpunit

You can define WP_TESTS_DIR in your .bashrc file for quicker use in the future.

This post is brought to you by Anthologize campaign supporter Demokratie & Dialog. D&D, a Major Sponsor of Anthologize (woo hoo!), is using WordPress and BuddyPress in amazing ways both to study the way that government policy affects youth and to get youth themselves involved in the development of said policy. I had a chance to get to know the very excellent Andreas Karsten of D&D at BuddyCamp Vancouver last year, and we have big plans to start a BuddyPress jazz band. Many thanks for your support of WP, BP, and Anthologize!

Setting up PHPUnit with MAMP

· 4 Replies

After a few hours of Googling and headdesking, I finally got PHPUnit up and running in my local environment. In the end, I had to make reference to a bunch of different resources. It was a convoluted enough process that I don’t think I can replicate step-by-step instructions, but I can at least list some of the stumbling blocks I hit along the way.

My setup: OSX (10.6.8), running PHP 5.3.2 from the MAMP package. Generally, the commands I give here will have to be run as root; use either sudo each time or enter the root prompt with sudo su.

The basic instructions for installing PHPUnit tell you to use PEAR:
[code language=”bash”]
pear channel-discover pear.phpunit.de
pear channel-discover components.ez.no
pear channel-discover pear.symfony-project.com
pear install –alldeps phpunit/PHPUnit
[/code]
But when you’re running MAMP, ‘pear’ may point to the wrong version of PHP – the version that comes bundled with OS X, or another of the versions that comes with MAMP. Make sure that you’re referencing the proper one (source). In my case, that means:
[code language=”bash”]
/Applications/MAMP/bin/php5.3/bin/pear channel-discover pear.phpunit.de
[/code]
and so forth.

As noted here and elsewhere, PHPUnit requires at least PEAR 1.8.1, but MAMP (or at least the version I have installed) ships with an earlier release. (You’ll know that this is the case, because when you try installing PHPUnit with the commands above, you’ll get a bunch of messages about required versions.) When I tried upgrading PEAR with the internal
[code language=”bash”]
/Applications/MAMP/bin/php5/bin/pear channel-update pear.php.net
/Applications/MAMP/bin/php5/bin/pear upgrade pear
[/code]
I got a “Nothing to upgrade” message. I ended up doing a sort of manual upgrade, using step 6 of these instructions:
[code language=”bash”]
cd /Applications/MAMP/bin/php5.3
curl -O http://pear.php.net/go-pear.phar
php go-pear.phar
[/code]
and then following the on-screen instructions for configuring PEAR.

I found that, in my situation, the automatically generated PEAR configuration files pointed to the wrong version of PHP. I used the instructions in this comment to lead me in the right direction. More specifically, when I looked at the PEAR config settings
[code language=”bash”]
pear config-show
[/code]
I saw immediately that some of the paths were pointing to the wrong version of PHP (at /Applications/MAMP/bin/php/ rather than /Applications/MAMP/bin/php5.3/). I reconfigured the necessary paths like so:
[code language=”bash”]
pear config-set doc_dir /Applications/MAMP/bin/php5.3/lib/php/doc
[/code]
and so on.

This got me to the point where I could fire up PHPUnit on my version of PHP, without getting a ‘command not found’ error. However, I didn’t get very far in my testing, because I kept getting fatal errors. In my PHP error logs, I could see that lines in PHPUnit, like the following, were failing to find their targets:
[code language=”php”]
require_once ‘PHPUnit/Autoload.php’;
[/code]
This suggested that the include_path in my php.ini didn’t have the correct directory. So I opened it up (on my installation, it’s at /Applications/MAMP/conf/php5.3/php.ini). It turns out that PEAR had attempted to rewrite the include_path directive but it had pointed to the wrong path for my purposes. I appended the following path (which is where PEAR keeps the PHPUnit package files): /Applications/MAMP/bin/php5.3/lib/php/PEAR

Et voilà – it finally worked:
[code language=”bash”]
phpunit –version
# PHPUnit 3.5.15 by Sebastian Bergmann.
[/code]