Stuart Herbert has officially released a plugin for the popular text editor Sublime Text 2 to integrate PHPUnit support directly into the editing environment.

Sublime Text 2 is a new cross-platform text editor that I've recently switched to. It's still in public beta, but already offers better performance (and battery life!) and a better look (fonts that render properly!) than Java-based IDEs such as Netbeans. One thing it didn't have was support for PHPUnit, so I've made a plugin. It's available to install via Package Control.

The plugin allows you to directly create tests for a class using a context menu's "Test This Class" option. You can also run the tests directly from the editor and use either the menu or direct text commands to control it. He's also gathering some other well-used PHP snippets into another related plugin, the Additional PHP Snippets plugin.

Sebastian Bergmann has shared a presentation he originally gave at an Etsy event covering some of the history behind the popular PHPUnit tool and the development it's been through.

When Noah Sussman asked me to give a Code as Craft Technology Talk last week when I was consulting for Etsy I immediately said yes. [...] Just like with a talk that I gave last year, I suddenly had a chain of associations in my head that I just had to follow. And down the rabbit hole I went once more ...

He talks about the origins of PHPUnit (and mentions a few other tools), the move from PHP4 to PHP5, a change in version control from SVN to Git and features of the tool including mock objects and data providers. He also notes that not all tests are "good tests" and how, sometimes, backwards compatibility breaks are a good thing.

Mike Purcell has a quick new post to his blog showing how you can run PHPUnit on one specific test using handy grouping functionality already built into the tool.

The other day I was debugging an error in one of my unit tests, and found it hard to track down because when I ran PHPUnit, it ran all the tests contained in the file where my problem unit test was located. After some Googling and reading the PHPUnit Api Docs, I found that you can specify a test, among other tests, by adding a comment with the @group annotation.

Using this "@group" annotation tells PHPUnit to combine these tests and allows you you specify a "--group" setting on the command line to only run those. He includes some sample code showing how it can be used. This can be very useful for combining results for certain kinds of tests (say, all related to bugfixes) without having to run everything all over again.

Mike Purcell has a new post to his blog showing a method he's followed to be able to use the popular PHPUnit unit testing software without having to go through the PEAR installer to get there.

PHPUnit is a great tool to protect us developers from introducing new defects when adding new features or re-factoring code. However there is one HUGE downside to PHPUnit; it must be installed using PEAR. Personally, I don't like 'auto-installers', I'd prefer to know what exactly is happening behind the scenes with regards to which libraries are required and how they are being called. [...] After breaking down the PHPUnit source code, I realized it could be installed without going through PEAR, and without too much headache.

He walks you through the directories you'll need to set up (test/vendor), the commands you'll need to get the latest version and unpack it, changes to set up some symlinks and updating the PHPUnit source to modify the autoloader, bootstrap and phpunit executable.

On DZone.com today Giorgio Sironi has a quick tutorial showing you how to set up and use the PHPUnit_Selenium component in the latest releases of the popular testing software.

With the 1.2 release, PHPUnit_Selenium supports (basically) for the first time the Selenium 2 WebDriver API. While PHPUnit_Selenium already worked with Selenium 2, it did so only by using the Selenium 1 emulation included in the jar; now it provides an object-oriented API right natively supported in a base PHPUnit test case, shipped in PHPUnit's PEAR channel.

He includes the steps you'll need to pull it from the PEAR channel and how to set up a test case based on the PHPUnit_Extensions_Selenium2TestCase object. He gives a few examples of how to select various components on the page (via CSS selectors and XPath), assert that the right information is there and interact with forms.

Chris Hartjes ran into an issue with hit unit tests where PHPUnit was throwing an "aborted" error no matter what tests were run. Thankfully, in this new post, he shares a solution.

That was a pretty annoying bug. I never did find out what the problem was as I moved onto other problems and chalked that error up to some undiagnosed weirdness on that particular server. From time to time I would get asked on Twitter if I had ever solved the problem. My answer was always "no, and if you do solve it please let met know how you fixed it." Today, my friends, was the day.

Based on a response from Demian Katz, he was able to get around the issue with flag set on the PHPUnit command line - "-dzend.enable_gc=0". Apparently the issue has to do with garbage collection and has been a known issue since the beginning of 2011.

In a new post to DZone.com Giorgio Sironi talks about the "open/closed principle" in software development and shows an example based on the design of the PHPUnit_Selenium project.

This article shows an example of how the application of the Open/Closed Principle improved the design of a real project, the open source library PHPUnit_Selenium. These design concepts apply to every object-oriented language, including Java, Ruby or even C++. The Open Closed Principle, part of SOLID set, states that software should be open for extension and at the same time closed for modification.

He starts with a little background on the project, pointing out that there's a Session object it uses for all of its testing with a magic "__call" method that handles any kind of method call to the object. This method has issues (dependencies, strict requirements for use) but can be refactored according to the Open/Closed idea to set up an array of anonymous functions that can be called as a "command". Examples of these types of classes are also included (one for the "click" action on a button and another for getting the current location).

Brian Swan has posted another in his "unit testing on Azure" posts to his blog today. This time he shows how to get VisualPHPUnit running on your Windows Azure installed code.

Last month, I wrote a post that outlined 3 ways to test PHP applications in Windows Azure, and since then I've covered two of those approaches: Running PHPUnit in Windows Azure (uses RDP) and Automating PHPUnit Tests in Windows Azure. In this post I'll cover how to use a web-front end (VisualPHPUnit specifically) to run tests in Azure.

The process is really simple - it's basically three steps (after the VisualPHPUnit install):

• Edit the configuration file to point to the right tests directory
• Password protect the VisualPHPUnit directory
• Deploy your application by following the instructions here

Brian Swan has posted another tutorial in a series looking at testing applications on the Azure platform. In this latest post he talks about how to automate your PHPUnit tests as a part of the start up of the instance.

In this post, I'll show you how to deploy your PHPUnit tests with your application, have the tests run as a start up task, and have the results written to your storage account for analysis. Attached to this post is a .zip file that contains a skeleton project that you can use to automatically run PHPUnit tests when you deploy a PHP application to Azure. I'll walk you though how to use the skeleton project, then provide a bit more detail as to how it all works (so you can make modifications where necessary).

He has it broken up into a few easy-to-follow steps:

• Download the AzurePHPWebRole zip archive and unpack it
• Copy your application, tests and PHP installation into the resulting file structure
• Create a skeleton "ServiceConfiguration.cscfg" file with the "cspack" command and edit it to change the "osfamily" and "osversion" settings
• Use "cspack" to package up the application and deploy the application

He walks you through the "how it works" steps too - the things that happen for you automatically on the server side to do things like set up the file to log to, configure the PHP environment and execute the "runtests" Powershell file as included in the AzurePHPWebRole download.

Brian Swan has a recent post to his MSDN blog about setting up PHPUnit for testing on a Windows Azure platform (as installed via PEAR).

After figuring out how to run PHPUnit from the command line in a Windows Azure instance, I did find that a bit more configuration work than I anticipated was necessary. I'm not 100% certain that this is the best way to run PHPUnit in Windows Azure, but it is one way. I'd be interested in hearing better ways to do this.

He breaks it up into a few different steps:

• Building the application with your tests locally
• Package the application up for Azure deployment
• Enable RDP access on your Azure instance
• Find your PHP and PEAR install on your instance and, logged in via RDP, add their locations to your current path
• Edit the phpunit.bat file to point to the right PHP location
• Execute the tests!

For other options for testing Azure-based applications, see Brian's previous post.