Home

Feed aggregator

Full Test Coverage is Impractical

Planet-PHP - Wed, 22/05/2013 - 21:21

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.

Categories: Open Source, PHP Community

Full Test Coverage is Impractical

Planet-PHP - Wed, 22/05/2013 - 21:21

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.

Categories: Open Source, PHP Community

Full Test Coverage is Impractical

Planet-PHP - Wed, 22/05/2013 - 21:21

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.

Categories: Open Source, PHP Community

Simplest PHP Generator Example

Planet-PHP - Wed, 22/05/2013 - 20:30

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.

Writing a Generator

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.

Using a Generator

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";
}


From this, you might assume that getValues() returns an iterator or array. I can imagine refactoring applications that absolutely do expect either of those to use generators instead, so that's intentional! If you do var_dump($stuff), however, you'll see an object of type Generator.

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.

When To Use Generators

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.

Looking Forward to Generators

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

Categories: Open Source, PHP Community

Simplest PHP Generator Example

Planet-PHP - Wed, 22/05/2013 - 20:30

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.

Writing a Generator

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.

Using a Generator

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";
}


From this, you might assume that getValues() returns an iterator or array. I can imagine refactoring applications that absolutely do expect either of those to use generators instead, so that's intentional! If you do var_dump($stuff), however, you'll see an object of type Generator.

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.

When To Use Generators

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.

Looking Forward to Generators

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

Categories: Open Source, PHP Community

Simplest PHP Generator Example

Planet-PHP - Wed, 22/05/2013 - 20:30

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.

Writing a Generator

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.

Using a Generator

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";
}


From this, you might assume that getValues() returns an iterator or array. I can imagine refactoring applications that absolutely do expect either of those to use generators instead, so that's intentional! If you do var_dump($stuff), however, you'll see an object of type Generator.

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.

When To Use Generators

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.

Looking Forward to Generators

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

Categories: Open Source, PHP Community

Reddit.com:

PHPDeveloper.org - Wed, 22/05/2013 - 18:52

Over on Reddit.com recently a discussion was kicked off asking people what framework they used for REST - their tool of choice for making API creation simple.

I was wondering what people here preferred for setting up REST APIs. Specifically if they had a preferred PHP framework for setting them up. in the past I had used CodeIngiter but am looking at Laravel some recently. I don't anticipate extremely heavy usage but I'd like to easily update the framework when it has new releases without a real pain working around my models and controllers.

Several different options were mentioned in the comments including:

Do you have a favorite you use for your REST APIs? share it here!

Link: http://www.reddit.com/r/PHP/comments/1em2ne/preferred_framework_for_rest_usage
Categories: Open Source, PHP Community, PHP.net

Reddit.com:

PHPDeveloper.org - Wed, 22/05/2013 - 18:52

Over on Reddit.com recently a discussion was kicked off asking people what framework they used for REST - their tool of choice for making API creation simple.

I was wondering what people here preferred for setting up REST APIs. Specifically if they had a preferred PHP framework for setting them up. in the past I had used CodeIngiter but am looking at Laravel some recently. I don't anticipate extremely heavy usage but I'd like to easily update the framework when it has new releases without a real pain working around my models and controllers.

Several different options were mentioned in the comments including:

Do you have a favorite you use for your REST APIs? share it here!

Link: http://www.reddit.com/r/PHP/comments/1em2ne/preferred_framework_for_rest_usage
Categories: Open Source, PHP Community, PHP.net

Reddit.com:

PHPDeveloper.org - Wed, 22/05/2013 - 18:52

Over on Reddit.com recently a discussion was kicked off asking people what framework they used for REST - their tool of choice for making API creation simple.

I was wondering what people here preferred for setting up REST APIs. Specifically if they had a preferred PHP framework for setting them up. in the past I had used CodeIngiter but am looking at Laravel some recently. I don't anticipate extremely heavy usage but I'd like to easily update the framework when it has new releases without a real pain working around my models and controllers.

Several different options were mentioned in the comments including:

Do you have a favorite you use for your REST APIs? share it here!

Link: http://www.reddit.com/r/PHP/comments/1em2ne/preferred_framework_for_rest_usage
Categories: Open Source, PHP Community, PHP.net

PHPMaster.com: Openbiz Cubi: A Robust PHP Application Framework, Part 2

PHPDeveloper.org - Wed, 22/05/2013 - 17:27

PHPMaster.com has posted the second part of their look at the Openbiz Cubi framework (part one here), this time focusing on the code - mostly XML - that you'll need to create your own custom module.

In the first part of this series we talked about the development challenges we face and how Openbiz Cubi can help by providing a solid, ready-to-use web application framework. In this part we'll see how to build our own module and dive a bit deeper into the core architecture of the framework.

They include the SQL you'll need to run to create a new table for the "Customer" module they're going to help you build. With that in place, they walk you through the command to execute to make the module skeleton, the locations of the XML files to work with and the contents of each. Included in the module are things like a data object, a module description file and the form object. He finishes up the post with a look at the overall flow of the Cubi execution so you know where each piece falls.

Link: http://phpmaster.com/openbiz-cubi-a-robust-php-application-framework-2
Categories: Open Source, PHP Community, PHP.net

PHPMaster.com: Openbiz Cubi: A Robust PHP Application Framework, Part 2

PHPDeveloper.org - Wed, 22/05/2013 - 17:27

PHPMaster.com has posted the second part of their look at the Openbiz Cubi framework (part one here), this time focusing on the code - mostly XML - that you'll need to create your own custom module.

In the first part of this series we talked about the development challenges we face and how Openbiz Cubi can help by providing a solid, ready-to-use web application framework. In this part we'll see how to build our own module and dive a bit deeper into the core architecture of the framework.

They include the SQL you'll need to run to create a new table for the "Customer" module they're going to help you build. With that in place, they walk you through the command to execute to make the module skeleton, the locations of the XML files to work with and the contents of each. Included in the module are things like a data object, a module description file and the form object. He finishes up the post with a look at the overall flow of the Cubi execution so you know where each piece falls.

Link: http://phpmaster.com/openbiz-cubi-a-robust-php-application-framework-2
Categories: Open Source, PHP Community, PHP.net

PHPMaster.com: Openbiz Cubi: A Robust PHP Application Framework, Part 2

PHPDeveloper.org - Wed, 22/05/2013 - 17:27

PHPMaster.com has posted the second part of their look at the Openbiz Cubi framework (part one here), this time focusing on the code - mostly XML - that you'll need to create your own custom module.

In the first part of this series we talked about the development challenges we face and how Openbiz Cubi can help by providing a solid, ready-to-use web application framework. In this part we'll see how to build our own module and dive a bit deeper into the core architecture of the framework.

They include the SQL you'll need to run to create a new table for the "Customer" module they're going to help you build. With that in place, they walk you through the command to execute to make the module skeleton, the locations of the XML files to work with and the contents of each. Included in the module are things like a data object, a module description file and the form object. He finishes up the post with a look at the overall flow of the Cubi execution so you know where each piece falls.

Link: http://phpmaster.com/openbiz-cubi-a-robust-php-application-framework-2
Categories: Open Source, PHP Community, PHP.net

PHPClasses.org: 5 Reasons Why the Web Platform War is Over: PHP Won with 75% says Google

PHPDeveloper.org - Wed, 22/05/2013 - 16:06

In this new post to the PHPClasses.org blog Manuel Lemos talks some about the recent introduction of PHP into Google's App Engine offerings.

During Google I/O 2013 event a Google manager said PHP runs on 75% of the Web sites. So they decided to finally support PHP as in their AppEngine hosting service. Read this article to understand why this puts an end to years of false claims that PHP was losing market, as well what it means to Web developers using PHP or other languages.

He looks at the App Engine PHP offering and looks at whether or not its a good platform to use for hosting your application. He points out some advantages and disadvantages (including no local file system access and no remote resource access). He also includes five reasons why the "web platform war is over" and why PHP has come out victorious:

  • Google Knows Because They Crawl the Whole Web
  • Google Does Not Influence Web Developers so much
  • Wordpress is the Dominant Blog Platform (not Blogger)
  • Programming Does Not Have to Be Beautiful
  • PHP Detractors Have the Wrong Focus

He admits, though, that PHP may not be dominant forever - it's not perfect, but there will always be a need for something that does what it can do (and does it well).

Link: http://www.phpclasses.org/blog/post/208-5-Reasons-Why-the-Web-Platform-War-is-Over-PHP-Won-with-75-says-Google.html
Categories: Open Source, PHP Community, PHP.net

PHPClasses.org: 5 Reasons Why the Web Platform War is Over: PHP Won with 75% says Google

PHPDeveloper.org - Wed, 22/05/2013 - 16:06

In this new post to the PHPClasses.org blog Manuel Lemos talks some about the recent introduction of PHP into Google's App Engine offerings.

During Google I/O 2013 event a Google manager said PHP runs on 75% of the Web sites. So they decided to finally support PHP as in their AppEngine hosting service. Read this article to understand why this puts an end to years of false claims that PHP was losing market, as well what it means to Web developers using PHP or other languages.

He looks at the App Engine PHP offering and looks at whether or not its a good platform to use for hosting your application. He points out some advantages and disadvantages (including no local file system access and no remote resource access). He also includes five reasons why the "web platform war is over" and why PHP has come out victorious:

  • Google Knows Because They Crawl the Whole Web
  • Google Does Not Influence Web Developers so much
  • Wordpress is the Dominant Blog Platform (not Blogger)
  • Programming Does Not Have to Be Beautiful
  • PHP Detractors Have the Wrong Focus

He admits, though, that PHP may not be dominant forever - it's not perfect, but there will always be a need for something that does what it can do (and does it well).

Link: http://www.phpclasses.org/blog/post/208-5-Reasons-Why-the-Web-Platform-War-is-Over-PHP-Won-with-75-says-Google.html
Categories: Open Source, PHP Community, PHP.net

PHPClasses.org: 5 Reasons Why the Web Platform War is Over: PHP Won with 75% says Google

PHPDeveloper.org - Wed, 22/05/2013 - 16:06

In this new post to the PHPClasses.org blog Manuel Lemos talks some about the recent introduction of PHP into Google's App Engine offerings.

During Google I/O 2013 event a Google manager said PHP runs on 75% of the Web sites. So they decided to finally support PHP as in their AppEngine hosting service. Read this article to understand why this puts an end to years of false claims that PHP was losing market, as well what it means to Web developers using PHP or other languages.

He looks at the App Engine PHP offering and looks at whether or not its a good platform to use for hosting your application. He points out some advantages and disadvantages (including no local file system access and no remote resource access). He also includes five reasons why the "web platform war is over" and why PHP has come out victorious:

  • Google Knows Because They Crawl the Whole Web
  • Google Does Not Influence Web Developers so much
  • Wordpress is the Dominant Blog Platform (not Blogger)
  • Programming Does Not Have to Be Beautiful
  • PHP Detractors Have the Wrong Focus

He admits, though, that PHP may not be dominant forever - it's not perfect, but there will always be a need for something that does what it can do (and does it well).

Link: http://www.phpclasses.org/blog/post/208-5-Reasons-Why-the-Web-Platform-War-is-Over-PHP-Won-with-75-says-Google.html
Categories: Open Source, PHP Community, PHP.net

Community News: Packagist Latest Releases for 05.22.2013

PHPDeveloper.org - Wed, 22/05/2013 - 15:09
Recent releases from the Packagist:
Categories: Open Source, PHP Community, PHP.net

Community News: Packagist Latest Releases for 05.22.2013

PHPDeveloper.org - Wed, 22/05/2013 - 15:09
Recent releases from the Packagist:
Categories: Open Source, PHP Community, PHP.net

Community News: Packagist Latest Releases for 05.22.2013

PHPDeveloper.org - Wed, 22/05/2013 - 15:09
Recent releases from the Packagist:
Categories: Open Source, PHP Community, PHP.net

Community News: Latest Releases from PHPClasses.org

PHPDeveloper.org - Wed, 22/05/2013 - 14:03
Categories: Open Source, PHP Community, PHP.net

Community News: Latest Releases from PHPClasses.org

PHPDeveloper.org - Wed, 22/05/2013 - 14:03
Categories: Open Source, PHP Community, PHP.net
Syndicate content