Assertions within PHPUnit SetUp/ TearDown

PHPUnit includes setUp() and tearDown() methods which are called for each test method. These are used to create pre-conditions for test methods or set up external resources used by each test.

It’s useful to note that assertions can be called within these methods to test if they have worked correctly, for example creating and then removing some database settings:

public function setUp()
{
	$this->db->set( 'foo', 'foo' );

	$this->db->set( 'bar', 'bar' );

	$this->assertSame( 2, $this->db->count() );
}



public function tearDown()
{
	$this->db->delete( 'foo' );

	$this->db->delete( 'bar' );

	$this->assertSame( 0, $this->options->count() );
}

Of course, if the assertions fail they’ll be repeated for every test method, but that’s probably better than wasting time investigating why tests are failing when it is setUp() that is the problem.

They can also be used to ensure that the tearDown() method has worked and doesn’t leave something persistent to interfere with subsequent tests.

Testing WordPress Plugins

Testing your code is essential – especially if you are going to publish it somewhere like the WordPress Plugin Directory. It takes no time at all for someone to find it and politely (or not so politely) point out it’s flaws.

So how do you go about testing a plugin within a WordPress installation? Easy, install WordPress locally, copy it into the plugins folder and of you go.

Hang on, what if you want to test it in another version of WordPress? Install that version and copy the plugin into that one too. How do you now merge changes between the two versions of the plugin?

Use WinMerge, or even better, subversion or GIT .. oh but my version control files are neatly organised somewhere else…

You get the picture.

The solution is to use symbolic links. A single working copy of the plugin is used and symbolic links to it are created from the plugin directory of each WordPress install you want to test it in. The only limitation is that the files need to be on the same computer.

I use a local Debian web server for development, so the first step is get into the terminal and go to the directory where I want to create the symbolic link:

cd /var/www/wp/4.5.3/wp-content/plugins

Then use the ln command to create the link to the location of the plugin files:

ln -s /var/www/wordpress-svn/dmg-text-widget/tags/1.0/ dmg-text-widget

The final part of the above command is the name of the link, which is the plugin folder name ‘dmg-text-widget’ in this case.

Then do the same in any other versions of WordPress that you need to test in, e.g:

/var/www/wp/3.1/wp-content/plugins

/var/www/wp/3.9/wp-content/plugins

/var/www/wp/4.0.1/wp-content/plugins

You can also create symbolic links on a Windows host – see this article on How to Geek for more info – but I haven’t tested it on Windows.