Stoyan Stefanov has come up against one of the frustrations of web development involving cookies - problems caused by the switch from a "www." in the host to none. He's come up with a test to show you how cookies are set and where you can access them from.

One of the implications of following the rule is related to the whole www vs no-www question. Basically you should always use www if you're planning to use any other sub-domains and you want them cookie-free. This is because you have no way to set a cookie only to the top-level domain.

His code sets cookies for the ".phpied.com", "phpied.com" and "www.phpied.com" domains. Since the domains without the "www" offer a bit broader range of possible matches, he recommends that if you're ever going to use any kind of subdomain, you'll want to use the more broad cookie to cover it.

Akash Mehta shares a helpful hint in this new post to the Developer Tutorials Blog today - testing out PHP code via the command line PHP binary.

Thankfully, PHP provides the interactive shell, allowing you to test out PHP interactively with immediate feedback. Here's how to take advantage of this mature feature of PHP.

With the help of the "-a" flag on the command line, the PHP binary will hand you an environment where you can code PHP and instantly see the results. He does mention a few quirks that make it different than working with PHP through a web server, namely moving in and out of code blocks and remembering to finish out with a semi-colon when the line is done.

New on the Debuggable blog today there's this post from Tim Koschutzki about a new feature he's contributed back to the CakePHP project. It allows you to run tests on the command line without having to worry about loading up a web interface to check your code.

It allows you to run all of the following: all core testcases at once, all core test groups, each core test case individually, all application-specific testcases at once, all application-specific test groups and each core test case individually. It also supports plugins, which means you can run plugin cases and groups.

He includes some samples of how it works - a few command line calls and what the output looks like.

In a new post to the Debuggable blog, Tim Koschutzki talks some about the work he's been doing on the code coverage analysis for the upcoming CakePHP release:

There are several different kinds of criteria to code coverage. The two most important ones are line coverage (or statement coverage as wikipedia puts it) and path coverage. [...] So how is it going to work? Pretty simple actually. Whenever you run a CakePHP test case Cake assembles information in the background about which lines of your subject-under-test are called.

He includes a few screenshots of the code coverage being run and the end result of the runner with the percent covered.

Sebastian Bergmann has posted some details about an update that's been made to the test runner for the PHPUnit (3.3) unit testing suite - an allowance for directories instead of just files on the command line.

Given a directory, the test runner will recursively scan the directory for *Test.php files, build a test suite out of the *Test classes, and run it.

PHPUnit is framework that makes writing tests for your code easy and also includes functionality to run the tests and analyze their results.

The mentor list for this year's TestFest 2008 has been started (as mentioned by Ligaya Turmelle on her blog). The list so far includes people from the community like:

• Elizabeth Smith (near Chicago)
• Pierre Joye (Munich)
• Sebastian Bergmann (Cologne)
• David Coallier (Ireland & various others)

Local organizers are still being assigned. Those considered must already committers at PHP.net and will be available to answer questions for their given areas. Ultimately, they will do the final commits of the resulting tests.

On the PHP.net website, the official announcement for TestFest 2008 has been posted:

The PHP-QA team would like to announce the TestFest for the month of May 2008. The TestFest is an event that aims at improving the code coverage of the test suite for the PHP language itself. As part of this event, local User Groups (UG) are invited to join the TestFest. These UGs can meet physically or come together virtually. The point however is that people network to learn together.

The event is not only a teamwork/friendship building effort but will also help out the PHP.net mentors in a serious way - testing has largely been their responsibility and having a wealth of user-submitted tests to help out cuts their workload dramatically.

You can find out how to get you and your local PHP user group involved, head over to the TestFest homepage.

Resulting from a conversation among developers at this year's PHP Quebec 2008 conference, a new event has been created to help test PHP against as many different configurations as it can be - TestFest.

The TestFest is an event that aims at improving the code coverage of the test suite for the PHP language itself. As part of this event local UG are invited to join the TestFest. All it takes is a local organizer to spear head the event and to get others involved in writing phpt tests. The submissions will then be reviewed by members of php.net before getting included in the official test suite.

The even will be announced sometime in March and its hope is to get as many people in the community involved to improve the language. There'll also be a raffle to give away 10 of the stuffed elePHPants as well as, for the ones who are "test worthy" and seem able to write up good tests on their own - commit CVS access to php.net as well as an official php.net account.

For more details on the event, check out this page on the (new) PHP.net wiki.

Ilia Alshanetsky has officially announced that the latest release candidate for the PHP 5.2.5 series (RC1) has been posted and is ready to test.

This RC includes a fair number of fixes since our last release and predominantly works on improving the stability of the 5.2 tree as well as including a small number of minor security fixes. I'd like to ask everyone to test this release against your code and setups, we are aiming for a quick release cycle and user feedback is critical for a successful release.

You can download this latest version here.

Reinhold Weber has put together a list of signs (40 in all on his "programming list of shame") that you're a lousy PHP programmer. Here's a sampling:

• don't see the need and/or benefits of a good programming IDE like Zend Studio or Eclipse PDT
• have never used some form of version control like Subclipse
• don't use a consistent methodology
• don't use test-driven development
• don't return content but echo or print it from your functions or classes
• return HTML, not data, strings, or objects.
• don't allow intelligent error handling
• you think reusable software equals/requires your code to be OOP

Now granted, some of them are a bit more high level than others, but if you're not headed towards a lot of these, you might change paths, hop out of that comfort zone and branch out into the community and the language a little bit more.