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.

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.

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.

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.

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.

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.

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.

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.

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.

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.