Stefan Priebsch has posted an overview of some of his experiences with test-driven development in PHP. Specifically, he talks about it in the context of a small CMS he's been working up.

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.

Padraic Brady has posted a manifesto of sorts about the work that he's been doing on his PHPSpec library and trying to work it into the approval process for the Zend Framework.

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.

Sebastian Bergmann points out that he will be speaking at the upcoming PHP Conference in Quebec (2008). He will be presenting three talks/tutorials:

• 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.

With test-driven development being promoted as one thing that can help encourage better coding, most developers are looking into its use and how it can help. Paul Jones takes an opposite approach, though, and looks at how it could cause "ravioli code" in an application.

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

On the "PHP in Action" blog, Dagfinn Reiersol has posted some ideas about developing PHP applications (really, any applications) from scratch - by faking it.

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.