On the ServerGrove blog there's a new post spotlighting one of the Symfony plugins they think is interesting - the sfBehatPlugin, an interface into the Behat system for behavior-driven development.

Quality assurance (QA) is one of the most difficult things to implement around software development. Most of time it is left for the final phase of development and very often overlooked entirely. As many experienced web development teams already know, QA needs to be part of the development process from the get-go. [...] Behavior development/testing is just one aspect of quality assurance.

They briefly touch on the installation of the plugin (Symfony plugins are usually pretty easy to get set up) and link to the project's homepage for more references on some of the basics of using it to act as a browser, parse the response and use forms on a page.

In a new post to his blog today Keith Casey talks about something that might be a bit foreign to some PHP developers out there event driven programming. He relate it to the Flex world where it's more commonly used.

When you initially dive into the world of Flex development, most PHP'ers will quickly notice something weird. We're out of the world of Request/Response that we know and understand and into an odd world of Events, Listeners, and Publishers/Subscribers where things just don't play well together.

He talks about the Observer design pattern and how it works to provide an interface to other objects who are listening in and waiting for events to happen (he uses an airline analogy). He also gives a more concrete illustration - uploading a file - and how the events would be used to handle each part of the process.

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.

The Zend Developer Zone has another new tutorial from Padraic Brady talking about testing your applications (i.e. unit tests). In this new article, he expands on his previous one and dives a bit deeper into the behaviour-driven development process.

In this article, I introduce a TDD related practice called Behaviour-Driven Development which has been gathering attention for over a year and gaining converts (like me!).

He briefly covers what BDD is and how it can be used to solidify code against issues that might come up down the road (and how it compares to test-driven development). Some sample code/tests are included to give you a better idea of how it all fits together - a set of scenarios for any given "story". True to the title, Padraic writes his tests around the construction of a Klingon Bird of Prey ship.

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.

In his latest post, Jason Sweat shares some of his experiences (and some code) surrounding his trip out to a PHPLondon meeting to be a guest speaker.

He talks about the location of the meeting (a pub named "The Hope") and some of the notes about his talk. The talk was a modified version of his Test Driven Development talk (given previously at php|tek). He changed it to appeal to people who hadn't really used unit testing in their development to explain why it's important. He includes the bit of sample code he used to illustrate his point - a test designed to ensure that the daily salary was being calculated properly. The presentation can be downloaded here as a PowerPoint file.

In his latest post, Jason Sweat shares some of his experiences (and some code) surrounding his trip out to a PHPLondon meeting to be a guest speaker.

He talks about the location of the meeting (a pub named "The Hope") and some of the notes about his talk. The talk was a modified version of his Test Driven Development talk (given previously at php|tek). He changed it to appeal to people who hadn't really used unit testing in their development to explain why it's important. He includes the bit of sample code he used to illustrate his point - a test designed to ensure that the daily salary was being calculated properly. The presentation can be downloaded here as a PowerPoint file.

Felix Geisendorfer shares, in this new post to the ThinkingPHP blog, some of his experiences with writing his code using test driven development.

So far I've had tons of fun trying to create php code using test driven development. It caused my code to become a lot more structured/consistent because writing the tests shows you interfaces problems right away. This is because the process of writing the test forces you to think a lot more about *how* you want to use some class / piece of code vs. your traditional "how can I get task x done"-thinking.

He also points out another benefit - it makes refactoring the code even easier (so there's more of a likelyhood that you'll use it again and again). He talks specifics about a library that he's been working on and the processes he's gone through to make things work with the testing versus his normal development cycle.

Felix Geisendorfer shares, in this new post to the ThinkingPHP blog, some of his experiences with writing his code using test driven development.

So far I've had tons of fun trying to create php code using test driven development. It caused my code to become a lot more structured/consistent because writing the tests shows you interfaces problems right away. This is because the process of writing the test forces you to think a lot more about *how* you want to use some class / piece of code vs. your traditional "how can I get task x done"-thinking.

He also points out another benefit - it makes refactoring the code even easier (so there's more of a likelyhood that you'll use it again and again). He talks specifics about a library that he's been working on and the processes he's gone through to make things work with the testing versus his normal development cycle.