In a new post to his blog Marco Tabini offers some suggestions on unit testing - not really a tutorial on how to it, more of an "easy way in" to introducing it to your development process.

Stopping development for weeks while you figure out how to add unit tests to cover your entire codebase is simply something that cannot be done (at least, not if you want to keep your job), no matter what future benefits it might bring. The good news is, adding unit testing to your existing project only takes five minutes - which is pretty much how long it takes to get a unit testing framework installed. That's it. Move on.

He puts the emphasis on unit testing to manage change in a code base, not so much to ensure that the current application runs as it should (not initially at least). He's found them most useful in bugfixing, refactoring and when adding new functionality. Current tests (and even tests written in TDD) can help with all of these. He includes reminders that if the tests aren't written well, they're useless and that once you've started testing, it needs to be continuous, even if they're not perfect.

In a new post to his blog Devis Lucato points out something he noticed when working with objects and anonymous functions/closures - they're not all as they seem.

Both solutions allow to instantiate an anonymous object with properties. They are used as value objects and have no other purpose than storing values, so no logic can be included and they don't come with methods. They can be used as function parameters instead of arrays, for instance. PHP 5.3.0 introduced anonymous functions and closures, so it is now possible to attach functions to these VOs (*). [...] The first thing to notice is that these properties are not methods but callable functions:

In his example, an anonymous function dynamically appended to an object doesn't have access to a property set on the object just one line before. There's a way around it with call_user_func, but it's not practical. His proposed solution is to create a type of Anonymous class that uses the __call method to catch the methods and translate them into calls to call_user_func_array automatically.

When developers start graduating from just hacking together scripts and want to start looking toward the future, one thing they start thinking about is making their code the best it could be. One way to achieve this is refactoring, but where to start? Well, this new post has an introductory guide to help developers understand this powerful technique.

Recently while on a drive with a non-programmer friend, I talked with him about code complexity and manageability, how very complicated code is detrimental to productivity and stuff like that. Later on, I decided to explain it to him with actual code examples, although the most he has ever done was some HTML back in elementary school.

He starts with a basic PHP+HTML+MySQL script that mixes the three and shows how to break it apart in steps - moving the PHP away from the HTML, creating functions and making a "template" for the database fetch results to display in.

Matt Curry has posted his review of the recently released "Refactoring Legacy Applications Using CakePHP" book from Chris Hartjes. The book looks to help developers get a better feel for using CakePHP in real-world applications.

Shortly after Chris Hartjes released his new book Refactoring Legacy Applications Using CakePHP he contacted me and asked if I'd be willing to review it. I jumped at the chance and Chris emailed me the DRM free PDF. After posting it to The PirateBay, I settled in and gave it a read.

Overall, Matt found the content of the book good but had a few things he might change - the "too smooth" nature of the update to CakePHP and the inclusion of a "partial refactoring" section (one that talked about only updating part of an application to the framework and integrating it with the rest of the site).

Chris Hartjes, a guru of CakePHP knowledge, is putting together a book - "Refactoring Legacy Applications Using CakePHP".

Some of you may know that I have started writing a e-book about CakePHP. I'm planning on publishing it myself for the low, low price of $7. I thought I'd let people take a sneak peek at how it looks so far by publishing the first two chapters in very rough form.

You can find a rough draft here (pdf). Keep an eye out on Chris' blog for more (possible) preview releases and for the final product once its wrapped.

Federico has posted a list of suggestions on things to look out for and to consider when you're refactoring your code.

Refactoring neither fixes bugs nor adds new functionality, though it might precede either activity. Rather it improves the understandability of the code and changes its internal structure and design, and removes dead code, to make it easier to comprehend, more maintainable and amenable to change. Refactoring is usually motivated by the difficulty of adding new functionality to a program or fixing a bug in it.

He's broken it out into a few topics with the suggestions underneath - things like looking at the "Big Picture", avoiding "Extreme Abstraction" and ensuring that your "Error Handling" is up to where it should be.

As mentioned by Ed Finkler, there's a list of signs your PHP needs refactoring from Soledad Penades.

I have had to go through a php application recently which has given me more than one headache and has required me to use all my possible patience. While working with it, I thought This is good material for an article, so that nobody else does the same in the future, and nobody else will need to experience the same displeasure as I have had to.

So here are the signs your PHP application needs a serious refactoring, right now

Included in the list are things like:

• Uses global variables
• Everything's an array
• The neverending switch
• Interface inconsistency

It hits on one of the thing that bugs me too, the problem of "Brackets galore" - so many subarrays that you have to resort to three or more sets of bracketed keys to get to the value you want. It's bad enough trying to follow someone else's code without having to "trace down" an array to figure out which of the values they're talking about.

Wanting to automate a common task he found himself doing, Raphael Stolt came up with his own process and use Phing to help.

To round off an older article on this blog called "Using the PHP 5 reflection API to keep track of unsolved refactorings" I wanted to automate the following task: collect and log some information about developer marked unsolved refactorings for a single class file or more common multiple files of an whole directory. And as I'm getting more and more acquainted with Phing I wanted to craft this custom task by using it's provided extension possibilities.

He gives examples of what the "unsolvedRefactoring" notation looks, the XML mapping for its definition, and the code that actually makes the mapping work - and makes it easy to pull out the needed information. There's two versions presented, one a normal pull and the other modified slightly to "actually retrieve the metadata of the methods marked as improveable via the @unsolvedRefactoring doclet". And, finally, the integration with Phing comes, showing how to run the files and what the results should look like.

php|architect has announced today that their July 2006 issue of their magazine has officially been released.

Articles in this issue include:

• Anant Narayanan's look at development in PHP-GTK 2 (cover story)
• Eric Angel's tutorial on using random images in form validation
• Stefan Priebsch's thoughts on code structure and refactoring
• and, of course, the Security Corner (with Chris Shiflett) and Test Pattern (with Jeff Moore) columns

You can either order a single issue or get a year's subscription of this great publication. The issue costs about $4.20 USD and the full year only comes in at $35.40 USD.

Ryan from Scarletlullaby.com has posted a new item today looking at the process he followed to refactor a Rails MVC application into PHP.

Most of my work of late has involved refactoring and rewriting insanely large and out of control programs so that it's easier to add features, follow program flow, etc. Since I've been using Rails so much in my personal projects, I tend to refactor things in a way that makes them resemble Rails in a funny, PHP-molested way.

I've come up with fairly decent and clean ways to implement most of the functionality available in Rails; basically, the PHP apps are set up using a frontcontroller, which delegates to instances of page controllers.

He looks at some of the "strange thoughts" he's had in the process, including issues dealing with POST/GET values, session data, and difficulty surrounding the fact that PHP dosen't support multiple inheritance.