PHP Community

Phix is a tool for creating and managing PHP components and tools and releasing them as PEAR packages.

I’ve pushed out Phix 0.16.0 this evening, with the following changes:

• phing build-vendor now removes the component’s own code from the vendor/ folder. (We build the vendor/ folder using PEAR, which installs the component into the vendor/ folder … sigh)
• An update to Phing changed the default behaviour of the <fileset> tag, breaking backwards-compatibility. I’ve updated our build.xml file to make the <fileset> tag revert back to its original behaviour.

To update your copy of Phix, please run:

pear upgrade phix/phix4componentdev


Any problems, please let me know.

• testing elements are (not) on the web interface
• users can't break out a certain flow on the web interface
• calculated values are correct after modification
• errors appear on screen when mistakes are made by users
• reported issues are valid

Truncated by Planet PHP, read more at the original (another 36325 bytes)

In her latest post Anna Filina proposes that full test coverage is an impractical way to measure the quality of your software. It can provide a false sense of security, even if the tests are poorly written.

She looks at how it's impractical to expect that all tests will be written efficiently or even correctly. Even simple tests are enough to show up on code coverage reports but may only be painting part of the picture. She also notes that not all software can be tested the same way - things like APIs require different testing skills/methods than something like consumer software.

In this new post to the ZFort blog Elena Bizina compares Symfony and Zend Framework from her perspective, looking at things like functionality, general understanding and community.

She first gives a high-level overview of each framework, pointing out a few of the features and tools they have built-in. She then goes on to answer the questions above, noting that she sees Symfony as coming out in the lead. Some of the questions are a little vague, so it's not entirely clear why one is different than the other. What do you think? Leave a comment here with your opinions.

On her blog Lorna Mitchell has posted an example of a basic generator written in PHP, a feature of the upcoming PHP version 5.5.

She includes an example of a very basic generator using the new "yield" keyword and how to implement it in a simple foreach loop. There's also a little talk about when is a good time to use generators in your applications (two examples: complex number calculation and working with large data sets a chunk at a time). For more information on how these generators will work, check out this page in the PHP manual.

On the Engine Yard blog today they've posted a conversation about testing between Ed Finkler and Chris Hartjes (also the hosts of the DevHell podcast).

They talk some about the current tools for unit testing in PHP applications and show what a sample test looks like. Ed talks about how the current testing tools can make it intimidating for people to get started testing and mentions the built-in testing library in Python that is a bit easier. There's also some mention of acceptance/functional testing and the Behat + Mink combo.

• piwik/piwik (1.12-b16) Open Source Real Time Web Analytics Platform
  
  
• mjohnson/utility (1.4.3) A collection of CakePHP utility libraries.
  
  
• superdweebie/identity-module (0.3) Zend Framework 2 Module that provides user management
  
  
• mjohnson/decoda (6.0.4) A lightweight lexical string parser for BBCode styled markup.
  
  
• lumedigital/wordpress-installer (0.1) Wordpress installer if you want to work with wordpress instances as full-package. eg. package to have wordpress files and references to plugins and themes
  
  
• kphoen/sitemap-bundle (1.1.4) Provides a way to create/generate a sitemap using Propel, Doctrine, etc.
  
  
• danielmewes/php-rql (1.5.2) A PHP client driver for the RethinkDB query language (ReQL)
  
  
• sabre/vobject (3.0.0-alpha2) The VObject library for PHP allows you to easily parse and manipulate iCalendar and vCard objects
  
  
• bcen/silex-dispatcher (0.4.2) A Silex plugin
  
  
• ncsuwebdev/base-otf-app (1.0.4) Base app for creating an OTF app
  
  
• ncsuwebdev/otframework (3.0.4) Base application framework
  
  
• ibrows/wizard-annotation-bundle (1.0.3) Simple wizard for a controller with validation methods
  
  
• havvg/cloudcontrol-bundle (v1.0.0-beta4) This bundle integrates your application on the cloudControl PaaS.
  
  
• havvg/dry-bundle (v1.0.3) A Symfony2 bundle providing helpers to ease usage of common patterns.
  
  
• kamisama/php-resque-ex (1.2.5) Redis backed library for creating background jobs and processing them later. PHP port based on resque for Ruby.
  
  
• aporat/php_gearman_daemons (1.0.0) PHP Gearman Deamon Manager
  
  
• paypal/permissions-sdk-php (v3.4.102) PayPal permission SDK for PHP
  
  
• paypal/merchant-sdk-php (v3.4.102) PayPal Merchant SDK for PHP
  
  
• paypal/invoice-sdk-php (v3.4.102) PayPal invoice SDK for PHP
  
  
• paypal/buttonmanager-sdk-php (v3.4.102) PayPal buttonmanager SDK for PHP
  
  
• paypal/adaptivepayments-sdk-php (v3.4.102) PayPal adaptivepayments SDK for PHP
  
  
• havvg/lock (v2.0.0, v1.1.0) A component for simple resource locking.
  
  
• mrprompt/cielo (2.0) Description of project Db.
  
  
• kitpages/data-grid-bundle (v1.7.0) Symfony DataGridBundle
  
  
• rah/danpu (2.5.0, 1.5.0) MySQL database dump and restoration tool implemented in PHP
  
  
• webmasters/doctrine-extensions (2.3.7) Doctrine2 extensions
  
  
• willdurand/geocoder (1.6.0) The almost missing Geocoder PHP 5.3 library.
  
  
• sammaye/mongoyii (1.2.4) A Yii MongoDB ORM
  
  
• payment/httpclient-buzz (1.1.0) http client bridge for buzz
  
  
• fiber/fiber (0.3.0) Dependency Injector Container
  
  
• pagon/fiber (0.3.0) Dependency Injector Container of Pagon
  
  

• PHPMaster.com: PSR-1 and PSR-2 to be Approved as Standards
• DeveloperWorld: How to make PHP apps scale
• 9Lessons.info: Login with Instagram OAuth using PHP
• Till Klampaeckel's Blog: Zend Framework: CRUD
• Phil Sturgeon's Blog: Laravel is Awesome
• Gonzalo Ayuso's Blog: Database connection pooling with PHP and React (node.php)
• Michael Nitschinger's Blog: A primer on PHP exceptions
• PHPMaster.com: 10 Tips for Better Coding
• Lineke Kerckhoffs-Willems' Blog: How to use the Symfony2 SonataAdminBundle
• Sean Coates' Blog: Use `env`
• PHPBuilder.com: Debugging Your Magento E-Commerce Applications in PHP
• Rafe Colburn's Blog: A list of engineering blogs
• Mike Purcell's Blog: PHPUnit - Upgrade - Convert assertType to assertInternalType
• NetTuts.com: 3 Key Software Principles You Must Understand
• PHPMaster.com: Introspection and Reflection in PHP

Many developers claim that to achieve high quality software, developers must create automated tests that ensure that all possible execution routes have been covered. This is also known as full path coverage. I will argue that different types of software require different testing approaches and that full path coverage is impractical in almost every case. Too many tests simply create clutter.

Let’s look at the impracticality first. Writing tests requires skill and effort. Everybody on your team is probably not a testing expert. Not only may it be difficult to get started with testing, but you will generate a great amount of code with its load of maintenance. Tests are not immune to their own errors either. I have uncovered a number of incorrect test cases in every project, including PHP itself.

A full coverage can give a fake sense of security, because you won’t second guess your tests and there will be too many to effectively audit them. That doesn’t mean that more tests is bad. It means that you must strike a good balance between the number of tests and the assurance that you are seeking. Look at it as a car insurance that costs more per year than the price on your car. You want to feel safe with the right insurance, but at some point, it’s more trouble than it’s worth. You can easily end up with more test code than software code, so watch out.

My second point is that different software justifies different tests. Software that is meant to be used by other software — such as a programming language, a framework or an API — would require more in-depth testing. I would recommend writing a few tests per function, to make sure that they return expected values. Testing all paths may still not be necessary, because some paths may prove redundant. Let’s take a date parsing function as an example. If you can parse “2013-05-22 13:00″ and “May 22, 2013 1:00pm” correctly, then perhaps testing the permutation “2013-05-22 1:00pm” may be unnecessary. Be smart about your tests: choose quality over quantity.

For consumer software, you may not need to test everything. I recommend to skip obvious tests. For example, it is obvious that when you first instanciate this class, getTotal() will return zero.

class ShoppingCart {
  protected $total = 0;

  function getTotal() {
    return $this->total;
  }
}

Writing overly obvious test cases is like underlining text that is already highlighted. I usually start testing areas that can have impact the business, such as losing data or selling 0.01 quantity of a product.

In the end, there are no exact rules on how much to test. The most important thing to keep in mind is that writing tests for the sake writing tests is futile and costly. Not only that, but your colleagues won’t bother reading or maintaining tests if they are only there for their own sake and provide too little value. Focus on building great software. Tests are a tool to make it better. Just don’t overdo it.

Many developers claim that to achieve high quality software, developers must create automated tests that ensure that all possible execution routes have been covered. This is also known as full path coverage. I will argue that different types of software require different testing approaches and that full path coverage is impractical in almost every case. Too many tests simply create clutter.

Let’s look at the impracticality first. Writing tests requires skill and effort. Everybody on your team is probably not a testing expert. Not only may it be difficult to get started with testing, but you will generate a great amount of code with its load of maintenance. Tests are not immune to their own errors either. I have uncovered a number of incorrect test cases in every project, including PHP itself.

A full coverage can give a fake sense of security, because you won’t second guess your tests and there will be too many to effectively audit them. That doesn’t mean that more tests is bad. It means that you must strike a good balance between the number of tests and the assurance that you are seeking. Look at it as a car insurance that costs more per year than the price on your car. You want to feel safe with the right insurance, but at some point, it’s more trouble than it’s worth. You can easily end up with more test code than software code, so watch out.

My second point is that different software justifies different tests. Software that is meant to be used by other software — such as a programming language, a framework or an API — would require more in-depth testing. I would recommend writing a few tests per function, to make sure that they return expected values. Testing all paths may still not be necessary, because some paths may prove redundant. Let’s take a date parsing function as an example. If you can parse “2013-05-22 13:00″ and “May 22, 2013 1:00pm” correctly, then perhaps testing the permutation “2013-05-22 1:00pm” may be unnecessary. Be smart about your tests: choose quality over quantity.

For consumer software, you may not need to test everything. I recommend to skip obvious tests. For example, it is obvious that when you first instanciate this class, getTotal() will return zero.

class ShoppingCart {
  protected $total = 0;

  function getTotal() {
    return $this->total;
  }
}

Writing overly obvious test cases is like underlining text that is already highlighted. I usually start testing areas that can have impact the business, such as losing data or selling 0.01 quantity of a product.

In the end, there are no exact rules on how much to test. The most important thing to keep in mind is that writing tests for the sake writing tests is futile and costly. Not only that, but your colleagues won’t bother reading or maintaining tests if they are only there for their own sake and provide too little value. Focus on building great software. Tests are a tool to make it better. Just don’t overdo it.

Many developers claim that to achieve high quality software, developers must create automated tests that ensure that all possible execution routes have been covered. This is also known as full path coverage. I will argue that different types of software require different testing approaches and that full path coverage is impractical in almost every case. Too many tests simply create clutter.

Let’s look at the impracticality first. Writing tests requires skill and effort. Everybody on your team is probably not a testing expert. Not only may it be difficult to get started with testing, but you will generate a great amount of code with its load of maintenance. Tests are not immune to their own errors either. I have uncovered a number of incorrect test cases in every project, including PHP itself.

A full coverage can give a fake sense of security, because you won’t second guess your tests and there will be too many to effectively audit them. That doesn’t mean that more tests is bad. It means that you must strike a good balance between the number of tests and the assurance that you are seeking. Look at it as a car insurance that costs more per year than the price on your car. You want to feel safe with the right insurance, but at some point, it’s more trouble than it’s worth. You can easily end up with more test code than software code, so watch out.

My second point is that different software justifies different tests. Software that is meant to be used by other software — such as a programming language, a framework or an API — would require more in-depth testing. I would recommend writing a few tests per function, to make sure that they return expected values. Testing all paths may still not be necessary, because some paths may prove redundant. Let’s take a date parsing function as an example. If you can parse “2013-05-22 13:00″ and “May 22, 2013 1:00pm” correctly, then perhaps testing the permutation “2013-05-22 1:00pm” may be unnecessary. Be smart about your tests: choose quality over quantity.

For consumer software, you may not need to test everything. I recommend to skip obvious tests. For example, it is obvious that when you first instanciate this class, getTotal() will return zero.

class ShoppingCart {
  protected $total = 0;

  function getTotal() {
    return $this->total;
  }
}

Writing overly obvious test cases is like underlining text that is already highlighted. I usually start testing areas that can have impact the business, such as losing data or selling 0.01 quantity of a product.

In the end, there are no exact rules on how much to test. The most important thing to keep in mind is that writing tests for the sake writing tests is futile and costly. Not only that, but your colleagues won’t bother reading or maintaining tests if they are only there for their own sake and provide too little value. Focus on building great software. Tests are a tool to make it better. Just don’t overdo it.

I really like the generators feature that's arriving in PHP 5.5, and since we're now into release candidate releases, it's actually not that far away. I've been speaking on this topic and I thought I'd share my trivially simple code example from my slides.

The generators use the yield keyword to feed values out as they are iterated over. In code, they really look a lot like a function (or method):

<?php
function getValues() {
    // totally trivial example
    yield "Apple";
    yield "Ball";
    yield "Cat";
}

The main difference is that this "function" will retain its state and yield the next value when it is used again.

It's not obvious from the calling code that a generator is in use - and that's a feature IMO. Here's an example that uses the generator declared above:

<?php
$stuff = getValues();

foreach($stuff as $thing) {
    echo $thing . "\n";
}

Each time the foreach tries to fetch the next item from $stuff, the getValues() generator gets called, and runs until a yield statement causes a value to be emitted.

There's nothing in these examples that makes a generator a better choice than, say, returning an array, so why are generators even useful? For the most part, they will be great for either formulaic or very large datasets. If you wanted to perform some task on all prime numbers up to ten digits long, you could certainly generate a list and iterate over it. However, that list could be quite large, and the generator could calculate and supply the next value on an as-needed basis.

The other use is for data sets which are large in comparison to the size of the memory available to PHP. A generator could fetch data in a loop, or read incrementally from a stream, and only have that one piece of data hanging around in PHP's memory at any one time.

Generators are just one more in a long string of understated features coming in to the newer versions of PHP, but it's one that will make your data-heavy applications run light and quick - I can't thank the PHP core team enough for bringing us this feature!

Lorna is an independent web development consultant, author and trainer, available for work (interesting projects only). This post was originally published at LornaJane