Now that Zend_Test has shipped, developers are of course asking, "How do I setup my test suite?" Fortunately, after some discussion with his colleagues and a little experimenting on it's one, Matthew Weier O'Phinney can answer that now.

This tutorial will set you through using Zend_Tool to jump-start development on your next ZF MVC application. Zend_Tool is both RAD tools as well as a framework for exposing your own set of tooling needs to the Zend_Tool user interface. While the areas in which extending Zend_Tool are exhaustive, we will focus merely on obtaining and using the current Zend_Tool toolset.

When testing code which uses the database, you would usually want to make sure the database stays pristine for each test - All tables should be empty, as any extra data could interfere with the tests. You could probably write an extended Testcase class which automatically does this before each test in setUp and afterwards in tearDown, but it may have some issues. For example, Zend Framework’s Zend_Test Testcase class also extends PHPUnit’s one, and you might need to extend the Zend_Test one as well… and so on. Luckily, PHPUnit has a way to add event listener that react to certain events.

Baron Schwartz, author of High Performance MySQL, got some interesting comments on his previous article about unit testing Maatkit, including echoes of my own conversion to the unit-testing religion. One of the objections he had heard a lot about unit-testing is how it’s impossible to test code that talks to a database. “It’s too hard,” they say. “Oh, it’s easy to test a module that calculates a square root, but a database? Way too much work!”

While developing PHP applications and applying developer testing the applications safety net will grow along the timeline, and as normal code, test code should be in a fresh, odour free state too. A common test code smell, amongst others, is the duplication of assertion logic which can reduce reusability, readability and thereby obscure the specific verification intention of tests. To subdue this special smell several patterns and refactorings are available to acquaint the test code with the DRY principle. So in this blog post I'd like to set the focus on some of the aspects of the Custom Assertion pattern, by showing how to create custom PHPUnit assertions, which attacks the above mentioned smell and its retroactive effects with a huge antiperspirant flagon, while also providing the chance to build a customer friendly and domain related test vocabulary.

There were many needs for it, in different mailing lists, forums and blogs, but it was never officially requested. There were also many approaches to accomplish it, but they were all kinda hacky. As DASPRiD neeed it in an earlier project yet, were he had to do the hacky way as well, and now a new project came up, were he even needed a more complex implementation, he decided to put a feature-rich hostname routing implementation into the ZF core itself. Read on to get a glance at it.

'Funny' Rails Envy Podcast Voicemail remix. In case you need a good laugh today listen to the remix, though the orginal voicemail it making some valid points. Way better than Terry Chays' PHP anthem.

Some weeks months ago I finally got my hands on the ThoughtWorks Anthology and got immediately hooked on one of the featured essays called 'Refactoring Ant Build Files' contributed by Julian Simpson aka the build doctor. After absorbing and studying the provided catalogue of overall 24 refactorings, I spent some time to transform a few health-promoting ones to the Phing universe. So the following post will outline six five basic, but valuable Phing build file refactorings by showing the smelly example first, followed by the scentless one and a closing refactoring description.

Jani Hartikainen provides are some ideas he was thinking of for making testing Zend Framework (and Doctrine) based apps nice and easy.

Since Matthew originally started hacking on the Zend Framework MVC in the fall of 2006, he has been touting the fact that you can test ZF MVC projects by utilizing the Request and Response objects; indeed, this is what he actually did to test the Front Controller and Dispatcher. However, until recently, there was never an easy way to do so in your userland projects; the default request and response objects make it difficult to easily and quickly setup tests, and the methods introduced into the front controller to make it testable are largely undocumented. So, one of his ongoing projects the past few months has been to create an infrastructure for functional testing of ZF projects using PHPUnit. This past weekend, Matthew made the final commits that make this functionality feature complete.

You may have heard of Dependency Injection. It’s essentially a way to remove implementation dependencies from classes, or “the process of supplying an external dependency to a software component. It is a specific form of inversion of control where the concern being inverted is the process of obtaining the needed dependency.” as Wikipedia puts it. Sounds complex? Yep. Is it complex? No. You might’ve even used it without knowing about the name.

Charles Nutter, a Sun engineer who has worked on the JRuby project, commented on PHP in a panel discussion at Sun's CommunityOne conference. I will not join the "PHP vs. Ruby on Rails" "discussion" here, as the comparison of a programming language to a web application framework for another language does not make sense, IMHO. Instead, I would like to comment on two of Charles Nutter's points.

More or less everybody who does test driven development comes to the point where one realizes that the preparation of the database before each test is vital - for good results and for your mental health. If you don’t do this properly then you will find yourself at some day searching through hundreds (or thousands) of tests to find the one which screws the database so that subsequent tests fail - even tough they are developed perfect. Ready more to get the 'Ruby way' approach.

Views in MVC are allowed to communicate with the Model (using read-only operations), and are allowed to perform display-related logic. That said, how do you actually access the model? And what if you have some fairly complex logic that you may need to repeat, or which you may not want to display directly in the view in order to keep it clean and easy to read? In Zend Framework, the answer is to use View Helpers.

This week I finally had the time to setup Xinc, PHP's shiny new Continuous Integration(CI) server, on my MacBook and started to fiddle with it's publisher plugins and plugin architecture. While still down with 'tool envy' influenza I recently came across some nice and inspiring blog posts from the Ruby/Rails camp, showing how to employ Growl as an useful and fun feedback radiator for test/spec results. Since then the idea of building a Growl publisher plugin for Xinc was travelling my mind repeatedly, so the following post will break this circle and show a possible approach to build such a plugin, which can be used to notify the build result for continuously integrated projects and thereby provide an on-point/immediate feedback.

Looking for an equivalent to Ant's -p(rojecthelp) command-line option in Phing, I dug up that you can use Phing's -l(ist) option to get a quick overview of all targets hosted in a given build file. This comes in handy when you are maintaining build files or have to get a raw picture of the provided targets of a project specific build file.

While still messing around with the PHP_CodeSniffer Pear package, I took a somehow jealous 1000 feet look at some prominent code inspection tools of the Java community: PMD and Checkstyle. Browsing their available rule sets/checks I soon recognized that guaranteeing the coding standard adherence is just a partial aspect of these tools. The following post will focus on one of these additional aspects, which is finding problems related to the code size of the inspected code artifacts, by showing how to port two selected rules to sniffs for utilization with the PHP_CodeSniffer tool. These ported sniffs can be used to automatically spot obvious code smells in the code base and to signal the need to apply the appropriate and odour reducing activity known as refactoring.

Scott Kim spent some time on developing a TextMate command for the PHP_CodeSniffer PEAR package.Check out it's blog post for more details and to get the Bundle including the command.

After finally converting to Mac OS X, I really couldn't resist to fall for the famous TextMate editor. The editor comes with a nice PHP bundle authored by Ciarán Walsh that eases the typing and creation of common language constructs like classes and control structures by entering pre-defined keys and hitting the tab key to insert and customize them. To reduce the typing effort for the most common tasks in creating a Zend Framework based application, which are creating action controllers including their hosted actions and creating new models for accessing the underlying database, I spent some minutes to figure out how to create and add these valuable snippets to the default PHP bundle.

In this article, Pádraic Brady introduces a TDD related practice called Behaviour-Driven Development which has been gathering attention for over a year and gaining converts (like him!).

Lately, the Zend_Layout component has been a very popular topic on #zftalk. It is indeed a very useful component, but a lot of people are having trouble understanding how it works. So Jani Hartikainen demonstrates the usage of the current Zend_Layout implementation, which can be found from the Zend Framework SVN or Snapshots in the Incubator directory.

As Zend_Layout is in the trunk now, Rob Allen provides a super simple MVC example that shows it in action.

For the last few days I've been reading the MEAP release of Zend Framework in Action from Rob Allen and Nick Lo published by Manning Publications and as a pre-review I d'like to share my reading experience. Currently there are 6 of totally 16 intended chapters available, if them are already worth the money you might want to read further.

PHPSpec is closing in on its first stable release, so the time had finally come to spruce up its output! No more the simple reporting of failed specs - now you get a few more details in a readable format, exceptions and errors even come with traces. In addition, Pádraic Brady implemented specdoc output as an option (using "-s") so you can get a list of specs in their plain text form.

Influenced by an article written by David Astel and the latest 'interest resurrecting' blog entries of Pádraic Brady, I was looking for a way to bend over the PHPUnit test-centric vocabulary to a more behaviour-centric one. The motivation for this 'NLP' is best justified by a quote from David Astel's paper "... if you want to change how you think it can help to first change your language".