On DZone.com today there's a new post written up by Mike Bernat about making web test cases for CakePHP applications with SimpleTest.

Most of the applications I work on have very straight-forward components and not a lot of complex functions/methods. I would only be testing whether or not they worked at all, rather than if they worked in a wide-array of situations. [...] For example, unit-testing a simple news list and detail page is probably overkill. Sure, you can test your classes by simple instantiating them but that only goes so far. My new method involves using SimpleTest's Scriptable Browser to actually crawl webpages and ensure that the proper data is being displayed.

He includes a few snippets of code to show how to implement SimpleTest's web test functionality - one that just checks a HTTP response values, another that checks for text on the page, one testing for a login on an admin page and a test for add/edit pages to ensure valid loading based on URLs/links.

Bradley Holt has a new post to his blog today talking about something he's a fan of in his development processes - rapid release cycles - and how something like the Zend Framework could benefit from it.

There has been some discussion recently on the Zend Framework mailing list around release cycles. I proposed a release cycle of six months for major versions (someone else suggested eighteen months, which may be more reasonable for a framework). Rapid releases allow one to accelerate the cycle of building, measuring, and learning. Gathering data from actual usage (measuring) provides an opportunity for learning that can be applied to the next release (building).

He points out that the post isn't specifically targeted at the Zend Framework project, merely that it was the inspiration point for the idea. He talks about what rapid release cycles are and what it can give the team that implements it - less worries about backwards compatibility breaks, a potential encouragement for development pacing and the ease for the customers doing upgrades.

A rapid release cycle allows you to apply new learning, knowledge, and perspective as often as possible. Do your best today, and give yourself opportunities to do your best in the future as well.

In the first of his "I will insult your code" series, Nate Abele looks at this submitted code and points out that maybe blocks of switch/case statements aren't such a good idea after all.

The entire submission is actually two files, which together comprise a console script for interacting with a web service (the names of the entrants have been withheld to protect the identities of the guilty). Rather than examine the full entry, we're going to take a look at one part which I find comes up fairly often: switch block overkill.

The example he's talking about has a switch statement with eight different cases under it, most of them just setting two properties on the current class. Its used ot map command line parameters to their correct properties. Nate suggests a bit different method - still using switch/case but pulling the properties to be assigned from an array of options rather than hard-coding them into the evaluation.

On the Debuggable blog today Tim Koschutzki looks at another testing topics for the CakePHP framework - a cleaner way for testing models.

Up until now there was always a need to create a so-called test model that extends your model-under-test in order to overwrite its $useDbConfig setting to be 'test_suite'. By that you ensured that your models run with the test_suite datasource when the tests are run. [...] Nate proposed ClassRegistry::config(), which allows you to tell the ClassRegistry class which datasource it shall use when ClassRegistry::init() is used the next time (and thereby a model is instantiated).

He includes an example of the new functionality - a test case ensuring that three articles are there and are marked as published. The registry makes it easier to automatically create the ArticleTest instance inside the test case rather than having to manually declare and define it.

New on the Debuggable blog, Tim Koschutzki has posted a method to get the fund() method in the CakePHP framework's models to bend to your will.

CakePHP allows you to use your own "find-types" for the Model::find() methodology. Those of your who are familiar with the find() method know that there are currently four types in the core: 'list', 'all', 'first' and 'count'. However, sometimes it is nice to specify your own type.

He shows an example of the end result - a find() call with a custom type that automagically gets translated correctly. His script overrides and enhances the usual find call in an extended object (extended from AppModel) that uses a switch/case statement to define the custom types and their find() search calls.

Sebastian Bergmann has a post about a new feature of the Workflow component in the eZ Components libraries - the Cancel Case Pattern.

Version 1.2 of the Workflow component that is part of the eZ Components adds support for the Cancel Case workflow pattern:

Once this Workflow pattern is called the complete Workflow instance is removed from the current execution (including any running nodes). You can find out more about the ezWorkflowNode in their documentation.

Mike Lively has posted about functionality he's created to add database testing procedures to preexisting PHPUnit tests supplementing his other post n adding database support to PHPUnit.

When I was first creating the Database Extension for PHPUnit I realized that there was a very high likelihood that several people would have tests that were already written that they would like to add additional database tests too. To accomplish this I actually wrote the PHPUnit_Extensions_Database_DefaultTester class. In fact, if you were to look at the source of the database test case you will see that all of it's operations are actually forwarded to this class which does all of the work.

He includes his same example from before - the banking system - and shows how the tests can be appended on, adding a getDatabaseTester method that returns an object the rest of the tests can use.

With all of the recent talk about business cases for PHP, Ben Ramsey wanted to get some of his thoughts on the matter out and into his blog in a new post.

I don't believe anyone has ever published any white papers on PHP, giving it a business case, and while we have companies like Zend, OmniTI, and eZ Systems providing support for PHP, I haven't seen any documentation from them like this. So, last Thursday when Google Group for developing a business case for PHP, I took notice and joined.

Definitely good to hear encouraging words about a project that could ultimately help out the language as a whole break into an area where the growth has been the slowest.

In a new post to his blog today, Stuart Herbert continues the theme he started in a previous post about a business case for PHP. In this new entry, he shares some things he's done to further the effort.

To turn this from an idea into reality, I've setup a Google group where anyone who is interested can join in, and help build this resource. Please come along with your ideas and concerns, and let's see what we can achieve together.

He also suggests some "first steps" to get the ball rolling, namely a list of topics the business case needs to cover.

In this new post to his blog today, Stuart Herbert suggests something that the PHP community really is in dire need of - a site/resource providing a place developers can point at to help refute some of the PHP rumors floating around and provide examples and test cases for one of the most stubborn PHP markets out there - business.

At work, we make and sell software written in a number of languages; our flagship product is written in PHP.

But one of the unfortunate side-effects of Stefan Esser's much-publicized departure from the PHP Security Team has been an increase in the number of IT staff we're coming across who "believe" both that open-source is inherently insecure, and that PHP in particular has incurable problems. These "beliefs" hurt ISVs trying to sell PHP-based applications into skeptical organizations.

He asks why there is no "Why PHP?" resource out there that clients/businesses in general can be referred to for better information. He also suggests one of the most logical fits for this kind of information and is surprised they don't really have something already - Zend. Check out the comments to see how much of the community is already behind the effort.