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.

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.

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.

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.

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.

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.

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.

The video linked to in the post shows more clearly how this functionality works, and also includes a bit more detail on the whole process, including a graphical representation of how the entire process works. Ajax wasn't actually used to send the message in this particular application - it's all just made with regular sockets.

He mentions three misconceptions to consider and avoid when developing a PHP application:

• The interface determines database design
• "I only need a small, simple database"
• "More tables makes for harder coding"