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.

The PHP.net has announced the availability of the latest Release Candidate in the PHP 5.4.0 series - PHP 5.4.0 RC6:

The PHP development team announces the 6th release candidate of PHP 5.4. PHP 5.4 includes new language features and removes several legacy (deprecated) behaviours. Windows binaries can be downloaded from the Windows QA site. [...] The 6th release candidate focused on improving traits. Please test them carefully and help us to identify bugs in order to ensure that the release is solid and all things behave as expected.

You can download this latest release from the PHP QA site (Windows binaries) and test it on your local instance/applications. Any and all feedback about issues should be reported to either the QA mailing list or on the bug tracker. A complete list of updates is available in the NEWS file.

In this recent post to his blog Stuart Herbert introduces a system he's created to handle "contracts" in PHP development - ContractLib.

Programming contracts are tests around functions and methods, and they are normally used: to catch any 'bad' data that has been passed into the function or method from the caller, and to catch any 'bad' data generated by the function or method before it can be returned to the caller. These are pre-condition and post-condition tests, and they are tests that either pass or fail.

He points out that by having contracts you not only increase the robustness of your code but you also save time not trying to hunt down data-related issues. Using pre-conditions, you can can check data to ensure things like correct formatting, data that's out of range and data that might be missing. His ContractLib comes with a set of tests that provide good examples of how to use the functionality. Installation instructions are included.

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.

On Reddit.com there's a recent post asking about testing developers as a part of the hiring process and how difficult it should be.

I developed an exercise for applicants. They must use an open source framework to make a simple bulletin board. It requires account creation, login, thread creation, message creation, unread message indication per thread, and logout. Every applicant is given this exercise after passing an initial test. The initial test is a simple disqualifier and is not challenging for anyone not lying on their resume.

There's some great discussion in the comments about things like the suggested time limit, opinions on other methods that could yield the same results, thoughts on the validity of even taking the test based on the level of the job. The popular opinion, though, is that it's too much work for an applicant to go through unless there's a very specific need. As one commentor put it:

Most of the excellent programmers will have jobs. Those that don't will probably have several options (unless you're in a very small market) for where to work. When it comes down to applying to the place that wants you to spend a bunch of your own time on their application, or some other company... They'll go with some other company.

On DevShed.com today there's the first part of a two-part series showing how to build self-contained validator objects that can be used to test the format of user input for validity.

In this two-part tutorial, I show why the use of static helper classes can be detrimental to building robust and scalable object-oriented applications in PHP (though you should take into account that the concept is language agnostic). I also implement a set of instantiable, fine-grained validators, which can be easily tested in isolation, injected into the internals of other objects, and so forth.

Their set of "concrete validators" are all based off of a validator interface/abstract class and check things like email formatting, floats, integers and URLs. Also included are a few examples of using the validators in a sample script.

As mentioned on the main PHP.net site, the latest Release Candidate in the PHP 5.4.x series has been released - PHP 5.4.0RC3:

The PHP development team is proud to announce the third release candidate of PHP 5.4. PHP 5.4 includes new language features and removes several legacy (deprecated) behaviours. Windows binaries can be downloaded from the Windows QA site. THIS IS A RELEASE CANDIDATE - DO NOT USE IT IN PRODUCTION!. This is the third release candidate. The release candidate phase is intended as a period of bug fixing prior to the stable release. No new features should be included before the final version of PHP 5.4.0.

Major changes include the introduction of UTS #46 mapping support in the intl extension and the inclusion of SERVER_NAME and SERVER_PORT into the $_SERVER superglobal for CLI. You can find more changes listed in the NEWS file and can download the latest from the PHP.net site (or your favorite mirror): source, Windows binaries.

In a new post over on DZone.com Giorgio Sironi shows how to create a fake, an interface that mocks the interface to an external tool and provides cached results back to the calling script.

We can specialize our Fake in a Self-Initializing Fake, which will provide an alternative implementation with the aid of the real one. In our Google Maps case, the Fake will use the real web service for its first response, and maintain an internal cache. This mechanism provides insurance about out-of-sync responses, and lets you enjoy the speed of unit tests after the initial warmup: if you always use the same data, no duplicate requests will be made to the external resource.

He includes example code for creating a test (with PHPUnit) that loads in the information from the Google Maps web service and caches it into a private variable inside the Fake. His test fails the first time checking for a difference in the time between fetching the real version and the cached version (fails the first time, but passes after the cache is implemented).

On DZone.com today Girogio Sironi shares some of his experiences testing out the PHP bindings currently offered to work with Selenium, the web application frontend testing tool that's become a standard over the past few years.

After trying out Selenium 2, it was natural for me to look for its support in PHP code; however, there isn't an official PHP Api distributed on Selenium's website. I tested all the PHP bindings I could find to see which is the best choice today.

He tried out a few different technologies:

• PHPUnit_Selenium
• Facebook's php-webdriver
• the php-webdriver-bindings project
• WebDriver-PHP

The finishes the post with a quick summary for each of the offerings including strengths each has and situations where you might want to use them.