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.

You know it; I know it. We should be testing our code more than we do. Part of the reason we don't, I think, is that we don't know exactly how. Well, I'm getting rid of that excuse today: I'm teaching you to test your PHP with the EnhancePHP framework.

He shows you how to download it, get it installed and creates a simple structure to do some TDD (Test-Driven Development) with it. His tests check three things - valid email addresses, username restrictions and phone number formatting. He also includes a look at creating mocks/stubs for a "scoreboard" example.

You can find out more about the EnhancePHP framework on its github page.

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.

At some point, many php developers turn to the pcntl functions in php to write a daemon, or server, or simulate threading. But how do you unit test this with complete code coverage? [...] We need to engage some black arts php extensions to make this happen. An installation guide follows, and the post ends with a complete listing of the unit test.

He uses the test_helpers extension (as provided by Sebastian Bergmann) and Runkit to allow the test to define new methods copying the current pcntl methods and mocks up the responses. Tests are included to check the parent of a process, checking the children of a process and testing that a fork could be made. Hes's even included visual proof of this working.

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.

Some watchful readers pointed out some subtle but nonetheless important bugs in the framework we have built yesterday. When creating a framework, you must be sure that it behaves as advertised. If not, all the applications based on it will exhibit the same bugs. The good news is that whenever you fix a bug, you are fixing a bunch of applications too. Today's mission is to write unit tests for the framework we have created by using PHPUnit.

He includes the XML for a basic phpunit.xml configuration file and uses a UrlMatcher and ControllerResolver in a "Framework" class and makes the test check for "not found" URLs and for checking for a correct Response.

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

Fresh off our holiday break, we're back with our longest show yet. We talk about Chris' new book The Grumpy Programmer's Guide To Building Testable PHP Applications, including his experiences self-publishing with Leanpub. Chris also explains how he fears no precipitation on his excursions to the Codemash conference in Ohio. Then Ed talks about the thought process that lead to his latest shit-stirring blog post "The MicroPHP Manifesto." Ed may or may not begin crying openly. Finally, we discuss when it might be necessary to trash your existing application and rewrite it.

You can listen to this latest episode either via the in-page player or by downloading the mp3 directly.

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.

This article is about how to mock the file system when writing unit tests, and it will be rather code-heavy. [...] PHPUnit is the de-facto standard for unit testing in PHP projects, and this is what we will be using together with vfsStream in this article.

The include the code for a simple storage driver (VGF_Storage_Driver_Filesystem) to use with vfsStream with "store", "delete" and "get" methods. Also included are examples of using vfsStream to check things like directory existence, if a file exists, or if a file can be read. A few simple assertions are set up in their sample test to check the methods in their "VGF_Storage_Driver_Filesystem" class.