In a new post to his site Matthias Noback has a post showing you how to, when using the Behat functional testing framework, to create local and remote code coverage metrics.

PHPUnit has built-in several options for generating code coverage data and reports. Behat doesn't. As Konstantin Kudryashov (@everzet) points out in an issue asking for code coverage options in Behat: "Code coverage is controversial idea and code coverage for StoryBDD framework is just nonsense. If you're doing code testing with StoryBDD - you're doing it wrong."

He starts off by talking about code coverage and why you might want it for the tests created through Behat. Code coverage metrics are usually associated with unit tests but having those numbers for the functional tests can be helpful too. He then covers the two pieces of the puzzle needed to gather the coverage numbers: an extension for the local coverage and one for the remote coverage. He shows how to get both of these installed, configured and used in the code to gather the results. Finally he shows how to use the phpcov tool to merge these results with the PHPUnit results to get a better overall view of coverage numbers.

In a post to his site Sergey Zhuk shows you how to get up and running on Travis-CI and Code Climate for generation unit test coverage with an integration between the two services.

When you maintain an open-source project it is considered a good practice to have a high test coverage, so the community can feel safe about using your code in their projects. There are some services that can analyze your code quality and provide some feedback about it. One of the most popular is Code Climate. This service doesn’t run your tests, but you can use one of CI tools to run them and then send their result to Code Climate. This article will show how to use Travis CI to run your tests and CodeClimate to get your test coverage.

The rest of the tutorial is broken down into five steps (well, five-ish - some have sub-steps):

• Get Your CodeClimate Reporter ID
• Add Your Code Climate Token To Travis CI
• Add CodeClimate Test Reporter Package
• Update phpunit.xml
• Update Travis CI Config To Send A Report

Each section includes the configuration changes to the .travis.yml or phpunit.xml configuration files you'll need to make to connect the services and generate the reports automatically.

Freek Lijten has a new post today continuing his look at the world of PHP extensions and focusing in on testing this time. He hopes to answer the question of what makes a good, effective set of tests to help increase the stability and quality of the extensions you write.

In my previous blog I took you through the process of getting PHP and extensions compiled, generating code coverage and running tests. What I did not talk about was what makes a good test. I hope to correct on this by adding this post and going into more detail on the actual writing of tests itself.

Using the same extension as before (enchant) he goes through the addition of a test for the enchant_dict_add_to_session function. He start by showing how much the function is currently tested (hint: none) and code coverage. He points out that 100% coverage is just one metric in a set that should be considered and not the final goal. He shares a simple test for the function that checks to see if a certain word exists in a dictionary. The coverage report shows all lines being executed, but there's a lot not tested, at least conceptually. He shows how to test "the spirit" of the function with additional tests for non-existent words, spell checking and if a word is not in the dictionary at all. PHP example code shows these tests kinds of tests to illustrate the steps he's talking about.

Brian Moon has a new post to his blog that pulls together some of his thoughts on monitoring PHP applications and how to handle the error that might be thrown.

PHP errors are just part of the language. Some internal functions throw warnings or notices and seem unavoidable. A good case is parse_url. The point of parse_url is to take apart a URL and tell me the parts. Until recently, the only way to validate a URL was a regex. You can now use filter_var with the FILTER_VALIDATE_URL filter. But, in the past, I would use parse_url to validate the URL. It worked as the function returns false if the value is not a URL. But, if you give parse_url something that is not a URL, it throws a PHP Warning error message. The result is I would use the evil @ to suppress errors from parse_url. Long story short, you get errors on PHP systems. And you don't need to ignore them.

He talks about the two-step process he's upgraded to to help monitor and handle the errors that pop up - an error handler that logs human-readable and json versions of the errors and something like Circonus to do metric tracking. He also mentions some external services recommended on twitter - HopToad and Loggly.

Sebastian Bergmann has posted about the latest release of the popular unit testing framework for PHP, PHPUnit 3.2.

I have just released a second release candidate for PHPUnit 3.2, the next major version of the xUnit testing framework for PHP.

According to the Changelog, updates in this new Release Candidate include a number of updates to the software metrics that can be run on code (at project, file, function, class and method level), the addition of DbUnit, code coverage improvements, bug fixes to the TestUI test runner and Selenium integration and much more.

Sebastian Bergmann has posted about the latest release of the popular unit testing framework for PHP, PHPUnit 3.2.

I have just released a second release candidate for PHPUnit 3.2, the next major version of the xUnit testing framework for PHP.

According to the Changelog, updates in this new Release Candidate include a number of updates to the software metrics that can be run on code (at project, file, function, class and method level), the addition of DbUnit, code coverage improvements, bug fixes to the TestUI test runner and Selenium integration and much more.

Sebastian Bergmann spotlights another feature of the upcoming PHPUnit version 3.2 - the inclusion of a Project Mess Detector's ability to help find duplicate code.

Duplicate code can be hard to find, especially in a large project. Johann-Peter Hartmann of MAYFLOWER GmbH recently implemented Copy & Paste Detection for PHPUnit's growing set of features that extends its usage scenarios beyond "just unit testing" to a one-stop solution for quality assurance in PHP-based projects.

In his example, Sebastian shows what the response will look like when the tests find duplicate code - giving details like the files involved and the code fragment that was duplicated.

Check out this list in another post on Sebastian's blog for more of the metrics that will be included in the upcoming version.

Sebastian Bergmann spotlights another feature of the upcoming PHPUnit version 3.2 - the inclusion of a Project Mess Detector's ability to help find duplicate code.

Duplicate code can be hard to find, especially in a large project. Johann-Peter Hartmann of MAYFLOWER GmbH recently implemented Copy & Paste Detection for PHPUnit's growing set of features that extends its usage scenarios beyond "just unit testing" to a one-stop solution for quality assurance in PHP-based projects.

In his example, Sebastian shows what the response will look like when the tests find duplicate code - giving details like the files involved and the code fragment that was duplicated.

Check out this list in another post on Sebastian's blog for more of the metrics that will be included in the upcoming version.

Sebastian Bergmann has a new post today about a different sort of use for the PHPUnit testing software - a "Project Mess Detector".

As of version 3.2, PHPUnit will not only be able to calculate and collect a variety of software metrics. It will also be able to report violations of rules that are based on these metrics in PMD's XML format. This information can then be fed to any tool that integrates with PMD.

The Project Mess Detector (PMD) software scans code and looks for potential problems. Having this integrated with PHPUnit means one less piece of software to run and the potential for even better written code.

Sebastian Bergmann has a new post today about a different sort of use for the PHPUnit testing software - a "Project Mess Detector".

As of version 3.2, PHPUnit will not only be able to calculate and collect a variety of software metrics. It will also be able to report violations of rules that are based on these metrics in PMD's XML format. This information can then be fed to any tool that integrates with PMD.

The Project Mess Detector (PMD) software scans code and looks for potential problems. Having this integrated with PHPUnit means one less piece of software to run and the potential for even better written code.