On PHPMaster.com today there's a new tutorial for those on the bleeding edge of PHP using the latest released version (5.4) and a feature that comes with it - using the built-in webserver that comes bundled for testing purposes.

One of the cooler features of the new PHP 5.4 release is a built-in web server designed specifically for development and testing. Now you can write and test your code without having to have a full-fledged LAMP configuration - just launch a the built-in server from the command line, test your code, and then shut it down when you're finished. [...] In this article I'll explain some basic uses of the new built-in server and show you how to build a portable personal development server useful for quickly testing your applications

He starts with a look at how to start up the web server (a simple command line switch and host/port definition) and the resulting default phpinfo page it displays. Other options include the ability to specify a document root for your server and create a sort of "front controller" for it to route requests. They show how to create a simple application based on this that can dynamically load in the index file, a router and pass the request off to the correct file. Their example includes some "niceties" too like logging, "hosts allowed" and checks for requesting directories.

You can find their full code for this example over on github.

In a new post to his blog Derick Rethans mirrors the call made by Rasmus Lerdorf at this year's PHP UK Conference - get involved (and help test PHP)!

At the PHP UK Conference Rasmus mentioned that he wants more people contributing to PHP. There are plenty of ways how you can do that.

Derick points out two more immediate ways you can help, one not even requiring any C knowledge:

• Help test the Release Candidates (like the current PHP 5.4.0 RC8) with a call to "make test" just after your compile.
• The recently added "random PHP bug" functionality that's been added to the bugs.php.net site

Chris Hartjes has taken some of his first steps to testing a web service with the help of the Behat BDD testing framework. In this new post he shares some of that knowledge and a bit of code to help guide you if you'd like to get started yourself.

I have been trying to push my JavaScript skills lately by first playing around with Node.js to get a feel for event-driven server-side coding and by trying to build something semi-useful using Knockout. [...] After working with PHPUnit's "assert that the result matches expectations" philosophy, switching to using a behavioural approach has changed how I decide to approach actually testing something.

He shows how to define a "scenario" in a more recognizable sort of English. His example is testing a web service to ensure of a few things:

• the response is JSON
• it contains at least one transaction
• the first transaction has an ID, contains two teams and has a description

Included in the post is the resulting Behat test code (generated and modified with his testing details) and an example of the execution of the test.

I think that the BDD approach maps better to a results-oriented methodology when it comes to testing: you are using real-life scenarios to make sure that you are getting back the results you are expecting. In the end. that is still the goal of testing.

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.