PHPSpec implements a domain specific language (DSL) in PHP for specifying the behaviour of functional units such as methods and objects. The purpose of a DSL was to move away from the xUnit style declaration of tests towards a specification language centred on describing behaviour.

He illustrates with a bowling example - described with a sample class (with a itShouldScore0ForGutterGame test) and how to use it to fit his proposal:

My proposal therefore is to re-implement the current programming language DSL as a specification language - i.e. a new (extremely limited and narrow!) language capable of being parsed by PHPSpec into its PHP equivalent. [...] Using a specification DSL, we can simply ignore the existence of classes in PHP (well, the pretense is nice). Instead the DSL would incorporate a syntax for denoting shared behaviours.

The ideal was to move away from line-by-line setup and manipulation of Zend instances towards a more simplified model which is standardised for any PHPSpec specs.

He's already created an "experimental branch" to work inside of and some of these updates have been made to the trunk for the release of PHPSpec 0.3.0. The key that he found was in getting the customization of the "Zend Context operational to set up elements of the FrontController". He also includes a simple example of the extended functionality in action - simple interface methods to work with Twitter.

My intention for the API is to facilitate Window's use of a soon to be announced tool for autotesting in PHP using PHPSpec.

He wants to use it in an automated testing environment that, when tests are detected in the current tests, runs the changed items and reports back the results via the Windows notification service. You can grab the code from the Google Code repository for it and test it our for yourself.

I'll be attempting to pound the Zend Framework into submission so I can apply Behaviour-Driven Development (BDD) using PHPSpec when I write a Controller. Why? Because I feel like it, and it gives me an excuse to promote one possible incarnation of PHPMock and the PHPSpec Zend Framework extension. See? Perfectly reasonable selfishness!

He hopes to move it past the typical test-driven development process that PHPUnit offers and "kick your ass into high-TDD gear" without having to have worked much with it before then (the key is simplicity).

He includes some code examples (how it should flow) and describes some of the challenges that he's coming across so far, specifically with the way that the Zend Framework works with the Controllers and what he wants to accomplish.

With the beta release behind us, I'm happy to announce the immediate availability of PHPSpec 0.2.0 from the project's pear channel at pear.phpspec.org or you can download directly from http://pear.phpspec.org/get.

Also included in his post are details about the release (like the Changelog), links to download the latest edition and some personal "thank you"s to developers who submitted patches to bring it from beta to a full release.

Mutation Testing is like testing, for tests. The idea is actually quite simple. Mutation testing adds small changes to your source code on the assumption that changing something, will most likely break it, which in turn means at least one test/spec should fail. [...] The reason why it's useful it that it gets around the problem of being over reliant on code coverage - just because some code executes when running tests, doesn't prove the tests will detect problems with it!

He wants to create a way that doesn't rely on external dependencies and is looking at working with the tokenizer functions native to PHP. He includes two examples of the way he's thinking - an example of simple token output and a way to go "backwards" to recreate the original source code.

PHPSpec is closing in on its first stable release, so the time had finally come to spruce up its output! No more the simple reporting of failed specs - now you get a few more details in a readable format, exceptions and errors even come with traces. In addition, I've implemented specdoc output as an option (using "-s") so you can get a list of specs in their plain text form.

He's also included an example of the new output in the post as well, showing the results of both successful and errored responses. You can check out the actual spec files on the googlecode repository for the project and get more details on the project itself (including the latest development snapshots) on the project's website.

I had a request to make a very quick summary of the PHPSpec API for the current development snapshots over on http://dev.phpspec.org. We're lacking documentation for right now, so here's a brief overview.

He describes some base assumptions about the development so far, conventions for making a valid spec class (including "fleshed out code" to make it work), a list of the Matchers currently available and a mention of the Predicates to help with the evaluations.

You can also check out some of his thoughts on the project and behavior-driven development as it hit its 100th Subversion revision.