Padraic Brady has posted about a part of his PHPSpec library, the domain specific language.

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.

Padraic Brady has officially released the latest version of his behavior-driven development framework PHPSpec 0.2.0:

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.

Padraic Brady has officially released the latest version of his behavior-driven development framework PHPSpec 0.2.0:

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.

In a new post today, Padraic Brady asks the community for any kind of input as to what they've seen for behaviour-driven development in PHP:

Behavior-Driven Development (BDD) is an evolution of Test-Driven Development (TDD) which pushes the focus away from the concept of testing to one of specifying behaviours in a form more easily understood.

In asking about any of the tools that might happen to be out there, he also gives an example (from a Ruby perspective) on how the behaviour-driven method is put into practice. The code describes the behaviour by what "it should" do and evaluates based on that.

In a new post today, Padraic Brady asks the community for any kind of input as to what they've seen for behaviour-driven development in PHP:

Behavior-Driven Development (BDD) is an evolution of Test-Driven Development (TDD) which pushes the focus away from the concept of testing to one of specifying behaviours in a form more easily understood.

In asking about any of the tools that might happen to be out there, he also gives an example (from a Ruby perspective) on how the behaviour-driven method is put into practice. The code describes the behaviour by what "it should" do and evaluates based on that.

Spurred on by some comments made in a thread on the php internals mailing list, Wez Furlong has posted this new item on his blog to help clear up some of the confusion around some "undefined behaviour" in the PDO libraries.

Wez goes on to mention that there are some issues with this in the Solaris manual pages as well, as based on others running into this same sort of problem. The realy key here, though, is how the documenttion is defined. Developers, in his opinion, show always treat situations that aren't expressly defined by the manual as a "situation is undefined" rather than making their own expectations.

Spurred on by some comments made in a thread on the php internals mailing list, Wez Furlong has posted this new item on his blog to help clear up some of the confusion around some "undefined behaviour" in the PDO libraries.

Wez goes on to mention that there are some issues with this in the Solaris manual pages as well, as based on others running into this same sort of problem. The realy key here, though, is how the documenttion is defined. Developers, in his opinion, show always treat situations that aren't expressly defined by the manual as a "situation is undefined" rather than making their own expectations.