Expanding on the previous post about how much testing may be too much, they're back with another post in the series, this time focusing on the "economy of tests". This time Mathias is joined by Konstantin Kudryashov as a co-author.

A common complaint with teams that first try their hand at automated testing, is that it is hard, costly, and not worth the effort. On the other hand, supporters say that it saves them time. In this post, we'll try to add some nuance to the discussion. We'll take a look at how different levels of automated testing affect the cost of development, both in the short and the long term, for both greenfield and brownfield projects. Finally, we'll look at a simple strategy for introducing tests and migrating them across test levels, in order to reduce maintenance costs.

They start with some baseline definitions so everyone's on the same page - unit test, integration testing and system testing. The article also covers some of the basic kinds of testing metrics including execution speed, fragility and understandability. It then moves on and looks at the other major final factor in the overall cost of testing, the age of the project (new vs existing). He mentions the Testing Pyramid, how it's recommended to migrate tests and some of the common opposing forces to the test migration/creation.

Lorna Mitchell has a recent post to her site showing you how to use Composer within an existing project that might not have the same Composer-expected structure. Composer is a package and dependency manager for PHP.

I've got an application (okay, scratty PHP script) which glues together some API things and shows them onto a dashboard for me. Recently, I updated it to use Guzzle as the consuming client, since twitter now needs me to authenticate (I wrote about that if you're interested), and I used Composer to bring the new library in. It was very simple so I thought I'd share it as it's quite minimal example, and those are my favourite kind.

She includes a brief "getting started" for those not already familiar with Composer and shows a sample composer.json file that pulls in the Guzzle HTTP library. Then calling the "install" with Composer pulls in the files in the right place and all you have to do is add the needed require_once include to your autoloading process. Composer handles the rest.

Phil Sturgeon, a developer on the Fuel framework project, has a new post to his blog asking a common question of all developers that set out to make the "Next Big Framework" - why write a new framework?

So we all know that the internet is full of frameworks. They've been the popular thing for the last 5 or 6 years and it seems to have become the "barrier for entry" or the "passage of rights" that 8 or 9 years ago used to be "hey I just wrote a phpBB clone!". There are plenty around but in this day in age, why would anyone write a new one? As somebody involved in a new PHP framework - Fuel - that has shaken a few opinions up I thought it would be interesting to share my thoughts and views on the situation.

While he agrees that there are plenty of other frameworks out there, maybe too many to choose from, he thinks that there's value in making something that's useful to you and the toolsets you're already used to. One of their goals with Fuel is to "make PHP as fun to use" as possible and things like built-in migrations and scaffolding (along with a command-line tool, Oil) help towards that goal.

A framework is essentially a way to put all of your best practises into a single place so that you can reuse them over and over again. This should make you more efficient and make your time more financially viable to clients. If the framework you use slows you down or does not cater for the way you like to develop then sack it off and do your own thing.

Mike Lively has posted about functionality he's created to add database testing procedures to preexisting PHPUnit tests supplementing his other post n adding database support to PHPUnit.

When I was first creating the Database Extension for PHPUnit I realized that there was a very high likelihood that several people would have tests that were already written that they would like to add additional database tests too. To accomplish this I actually wrote the PHPUnit_Extensions_Database_DefaultTester class. In fact, if you were to look at the source of the database test case you will see that all of it's operations are actually forwarded to this class which does all of the work.

He includes his same example from before - the banking system - and shows how the tests can be appended on, adding a getDatabaseTester method that returns an object the rest of the tests can use.

Mike Lively has posted about functionality he's created to add database testing procedures to preexisting PHPUnit tests supplementing his other post n adding database support to PHPUnit.

When I was first creating the Database Extension for PHPUnit I realized that there was a very high likelihood that several people would have tests that were already written that they would like to add additional database tests too. To accomplish this I actually wrote the PHPUnit_Extensions_Database_DefaultTester class. In fact, if you were to look at the source of the database test case you will see that all of it's operations are actually forwarded to this class which does all of the work.

He includes his same example from before - the banking system - and shows how the tests can be appended on, adding a getDatabaseTester method that returns an object the rest of the tests can use.

DevShed continues its look at using the GD graphics library in PHP with the second part of the tutorial series, this time focusing on the creation of images from existing images (and their streams).

As I stated at the end of the previous article of this series, the GD extension comes packaged with many other useful functions, which indeed deserve a close and detailed look. Thus, in this second tutorial I'll show you how to create different types of image streams from existing graphics, but in this case limiting the process to building GIF, JPG and PNG images.

They work through each of the types (GIF, JPG and PNG) creating an new one from a previous "clouds" image of the same type (a GIF out of a GIF, a JPG from a JPG, etc).

DevShed continues its look at using the GD graphics library in PHP with the second part of the tutorial series, this time focusing on the creation of images from existing images (and their streams).

As I stated at the end of the previous article of this series, the GD extension comes packaged with many other useful functions, which indeed deserve a close and detailed look. Thus, in this second tutorial I'll show you how to create different types of image streams from existing graphics, but in this case limiting the process to building GIF, JPG and PNG images.

They work through each of the types (GIF, JPG and PNG) creating an new one from a previous "clouds" image of the same type (a GIF out of a GIF, a JPG from a JPG, etc).

Well, according to Soledad Pendaes, PHP will never have a (real) Rails-like framework because of some of the limitations with objects inherent to the language.

I know the title is harsh but it's so true. At least it is according to nowadays php's implementation of classes and objects, which do not permit to "reopen" and add or redefine new methods to an existing class definition, which is the basis upon Rails (and I presume lots more of applications and frameworks) is built.

The post goes on to talk about they "why" behind the statement - basically that this kind of functionality makes it easier to "Extend. Morph. Adapt. Improve. Refine." your applications. She talks some about other frameworks that have tried to offer the same kinds of functionality Rails does (CakePHP and Symfony) but notes that they still have their limitations (in specific, mentioning CakePHP's AppModel functionality).

Well, according to Soledad Pendaes, PHP will never have a (real) Rails-like framework because of some of the limitations with objects inherent to the language.

I know the title is harsh but it's so true. At least it is according to nowadays php's implementation of classes and objects, which do not permit to "reopen" and add or redefine new methods to an existing class definition, which is the basis upon Rails (and I presume lots more of applications and frameworks) is built.

The post goes on to talk about they "why" behind the statement - basically that this kind of functionality makes it easier to "Extend. Morph. Adapt. Improve. Refine." your applications. She talks some about other frameworks that have tried to offer the same kinds of functionality Rails does (CakePHP and Symfony) but notes that they still have their limitations (in specific, mentioning CakePHP's AppModel functionality).

In this new blog post, Stoyan Stefanov shares a method he's found to reuse an existing database connection with the MDB2 library.

This is a follow up to a question posted by Sam in my DB-2-MDB2 post. The question was if you can reuse an exisitng database connection you've already established and not have MDB2 creating a second connection.

He gives two different methods, one for persistent connections and the other for non-persistent ones - including some code.