PHPSpec is the first ever PHP BDD framework. It is a port of RSpec to PHP created back in 2007 by Padraic Brady and Travis Swicegood. Development in this framework stopped for a while and was reignited last August (2010).

He goes over how to get it installed via PEAR and how to write some sample tests following along the topic from his previous post (handing videos and reviews). He gets into a bit more detail by describing how MVC is handled with PHPSpec and how the Zend Framework command line tool can be used to create a controller that satisfies the test.

I couldn't find any recent surveys looking into the percentage of software development teams that make use of TDD, but i'd hazard a guess that it's probably not as high as it perhaps should be. I think there are a number of reasons for this, but it's primarily all about the people. The technologies are here, you've just got to start using them - which begins by understanding why they should be used. [...] There are a number of test frameworks for PHP, the biggest of which are probably PHPUnit and SimpleTest. My preference is for PHPUnit, which is the one I'll be using here.

He walks you through the basics first - installation of PHPUnit from its PEAR channel and setting up some basics tests. From there he moves into the TDD-ness stage, creating a sample class to test the getting and setting of values from a configuration class. He also provides the class that's something like your end result should be.

Testing your code is annoying, but the impact of not doing so can be orders of magnitude more annoying! In this article, we'll use test-driven development to write and test our code more effectively.

They start with the basics - what test-driven development is, why it's a good idea and how the whole process works to improve your code. They opt for a bit simpler route for their testing tool and chose SimpleTest. They show you how to set it up and where to start. In order for TDD to work, you really have to plan out your application so you know what you're testing. They give you an example of a simple script and how to start from failing tests to a working app.

Acceptance Test-Driven Development is an Agile technique that extends the test-first approach to the development of the front end of an application. The mechanics of Acceptance TDD are clear: first you write a test which defines the goal of your development, which is basically the feature you're adding to your application. As with all TDD variants, this test must fail.

With the help of the Zend_Test component, your tests can execute through the full MVC stact of your application (including views) to check to see if the resulting content matches certain criteria. He includes a few code examples showing content searching (contains), validating the query string and checking for a redirect.

Over the past few days I was going through the Zend Framework reference docs and I found myself pleasantly surprised with all that the latest version of this web application framework provides. [...] Out of the many new features, what stood out for me was the ease with which Zend Framework and PHPUnit complement and work with each other.

He talks about some of the features of PHPUnit (including dependencies, testing for exceptions and errors) and how it fits into a good deployment strategy. He shows how you can use the Zend_Test component of the framework, along with the Zend_Test_PHPUnit features, to make a sample test case. There's also an example of using the Zend_Test_PHPUnit_Db component to test database information and your backend data stores to compare them to a formatted XML document.

The CMS I am using is a small engine that puts together (potentially multi-lingual) page content, templates, and a site structure, and creates semi-static pages. It does not have a sleek GUI frontend, because by nature I am not afraid of a text editor, and most of the time get quicker results by just writing HTML than fighting with one of these what-you-see-is-what-you-might-get HTML editors.

He talks about the configuration files containing the app's settings (inspired by the YAML Symfony uses) and his work towards the "best matching pattern" algorithm. This is where the TDD came in - he cheated a little with some base classes (tests first!) and then came up with the tests for checking template names and more complex template interactions.

The post includes drops of code here and there as well - examples of the unit tests and of the configuration files.

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.

• Test-Driven Object-Oriented Programming - Learning and Understanding (with Marcus Borger): This PHPLab is an in-depth introduction to object-oriented and pattern-based programming using PHP 5. You will learn everything necessary to write your own cutting-edge components and applications - and of course how to use and extend components from other people or companies.
• PECL: The PHP Language Workbench: A look into PECL shows how flexible the language core of PHP, the Zend Engine, is.
• Graph-Oriented Programming with PHP: This session presents the eZ Components' workflow engine, its possible applications and the underlying principles and techniques.

You can find out more about the conference from their main website (including other speakers that will be presenting) as well as registering to reserve your space for the March 12th-14th conference.

I know that test-first and test-driven development (TDD) are popular methodologies these days, but something about those processes has always met with a level of mental resistance from me. Even though it sounds good in theory, I have been intuitively wary of the "test-first" mentality for some reason. My own approach is closer "remember to code so you can test it later" and then "test-last" after the API is mostly stable.

He includes quotes from Slashdot comment quotes from AuMatar and dkf. Be sure to check out the comments on the post (17 of them at the time of this posting) for some opinions from others about test-driven development and how it can affect your code.

Blogs also mentioning this discussion:

• PHP in Action
• another post from Paul on some of the responses

So where and how on earth do you start? Let's say we know one thing about the result; call it the known fact. Do we start by making educated guesses about what should be in the black box? A lot of development is like that.

Enough of this philosophical mumbo-jumbo; what does it mean in practice? Well, it's test-driven development, and more specifically, it's what Kent Beck calls the Fake It patttern. You implement a test for the result, then you hard code the result. It's an absolutely weird idea that's magical in its effect because it get you started. And as the German expression goes, aller Anfang ist schwer--all beginnings are difficult.

He illustrates the point with a set of code examples - one side being the unit test (written first, of course) and the other the actual code. All it does is set a URL to a variable inside a class, but the point is made.

Starting at the high level is good when you know the full scope of the project, but that's not always a possibility. This is a good alternative to getting started without causing too many issues down the road.