There is generally no point in having code coverage for Behat test cases because of their nature: The purpose of an acceptance test is to assert a certain behavior of an application, not to technically test a piece of code. Therefore, there is no point in checking for uncovered code pieces in order to write a Behat test for it. That said, there is still a scenario where you want to peek at code coverage of Behat tests: When creating them as wide-coverage tests before starting to refactor legacy code. Behat in combination with Mink provides you with a great tool for such tests.

They help you get the tools installed and show the code you'll need to add to the application itself to collect the coverage data as the tests execute. It keys off of a file existing/not existing to know if it should execute the coverage or not. The phpcov tool can then be used to generate the HTML output of the coverage information for easy viewing.

Fresh off our holiday break, we're back with our longest show yet. We talk about Chris' new book The Grumpy Programmer's Guide To Building Testable PHP Applications, including his experiences self-publishing with Leanpub. Chris also explains how he fears no precipitation on his excursions to the Codemash conference in Ohio. Then Ed talks about the thought process that lead to his latest shit-stirring blog post "The MicroPHP Manifesto." Ed may or may not begin crying openly. Finally, we discuss when it might be necessary to trash your existing application and rewrite it.

You can listen to this latest episode either via the in-page player or by downloading the mp3 directly.

Three weeks ago PHPUnit 3.6 was released and it has a little new feature you might have missed until now. PHPUnit can now show you code coverage information on the command line.

Options for the report output include: colorizing, writing the output to a file, including a project summary, namespace separation and package (using the @package phpdoc tag) information. He includes a use case he's found for it - small projects where you can cover the whole codebase quickly (with a "watch" command example filtering based on a certain class).

In this fifth part of a series on using the Xdebug extension to help debug your PHP programs, we'll take a closer look at the xdebug_start_code_coverage() and xdebug_get_code_coverage() functions. Specifically, we'll see how we can extend their usage when working with conditional statements. As always, we'll complement theory with a number of hands-on examples.

They start with a review of the previous tutorial (that started the look at code coverage) and continue on to show how to extend a code coverage class to debug some conditionals and return the results in a simple echoed output.

Overall 158 tests have been submitted as part of TestFest 2008 since the launch of the TestFest submission site by 30 different people from people all over the world. Actually this is not counting the various submissions by existing core developers, who also took this opportunity to add some more tests. This has actually increased total test coverage by about 10%.

It also mentions Felix De Vliegher who, because of his large volume of tests (and quality of them), was granted commit rights into the PHP repository to add his in himself. The list of elePHPant winners is included as well. You can also still submit tests through the TestFest submission site (just not for any of the rewards).

• the php|tek live site
• slides (as they get them
• Photos on Flickr tagged with "tek08"

• Ivo Jansch: Day -1, Day 0, Day 1, Day 2, Day 3 (and wrapup)
• Eli White: Heading to php|tek
• Greg Beaver: phar is near at php|tek
• Ivo Jansch's coverage of the Zend/Microsoft issue during Joe Stagner's keynote
• Brian DeShong's slides - The Grown-Up Company's Guide to Development and Robust Batch Processing with PHP
• Maggie Nelson slides - Keeping You DB and PHP in Sync, Angering the Database Gods
• Sebastian Bergmann's slides - Type-Safe Objects in PHP, Understanding the PHP Object Model, Quality Assurance in PHP Projects
• a wrapup of the conference from Ben Ramsey
• Matthew Turland's look back at the conferece
• Gennady Feldman's wrapup
• Maggie Nelson's slides for Angering the Database Gods
• a heads-up from Marco Tabini to look in the near future for some incriminating video of some php|architect staff in KISS outfits
• Jeff Moore's wrapup of this year's conference and links to his slides - Exceptional PHP and Coding for Success: Writing Software You'll Be Able To Understand Next Month
• Another recap by Andrew Culver
• slides from Greg Beaver - PEAR, Phar and Smart PHP
• slides from Ed Finkler's talks - Building Desktop RIAs with PHP, HTML & Javascript in AIR, Securing the PHP Environment with PHPSecinfo
• an overview from Christopher Jones

Check out more live from the conference on the php|tek Live page on the php|architect website.

It took us about 2 years to get the last 5% and I believe most of the kudos should go to IBM people, who continue to contribute lots of new tests. I hope that the Testfest will help us to speed up this process.

There are still a lot of items in the red that could use some tests, so if you're looking to help out write up some tests or check your area for a TestFest event to get some help.

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.

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.

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.