While PHPUnit is awesome out of the box, it still lacks some tools that are required to do things like test protected class methods or assign values to protected class attributes. Lucky for me we have an awesome testing engineer at Kaplan named Will Parker who has shown me some ways that they have extended PHPUnit itself to make testing certain things easier.

Chris talks about things like testing protected methods (easy thanks to a helper) and checking the value of a class property. The key to both of them lies in using PHP's own Reflection functionality to alter properties on the class objects themselves.

Still returning false whenever a function in your program fails? In this article, we'll learn about PHP exceptions, and how you can use them to soup up your application's error handling.

The include some of the methods you can call on your exceptions (including getting the message, code, file, line and the results of a debug_backtrace right before it was thrown). Included is code to throw exceptions, catch them with a try/catch and using error codes as return values and extending them to fit your own needs.

This is just a short follow up to a recent tweet of mine. I have seen this repeatedly happen, even to top notch and usually very careful developers (*). I am not sure why this mistake happens so frequently, but quite often you see code that changes the parameter order for custom Exception constructors. I guess it's mostly because in these cases the developer wants to pass some magic parameters that contain the message (and potentially also the code).

He recommends that, if you really do need to change something like the order of the parameters, use something like a factory to handle the reorganization for you.

It's important to have a common understanding of the actual problem area. When we talk about names, we are really talking about the API. An API is a particular set of rules and specifications that a developer can follow to access and make use of the services and resources provided by another particular software program, component or library. Put another way, it is an interface between various software pieces and facilitates their interaction, similar to the way the user interface facilitates interaction between humans and computers.

He talks about the two different APIs you're usually building at the same time - a consumption API that is the method others use to consume it and the extension API, how the feature allows others to improve upon it. He shares his own API philosophy and a three tips he's learned along the way to make his APIs more robust:

• Adopt A Common Namespace & Class Naming Scheme
• Avoid Doing Too Much In the Constructor
• Avoid final And private

When taking Phone number as user input, we can worn users about phone number format by setting a hint/description and can validate using Regular Expression. [...] Now, if we try provide this feature in Zend Form, that's possible. We can create three individual Zend_Form_Element_Text objects and join there value together to make the phone number. But, in this case, validating them together is a hassle.

Instead of separate fields, the library they create makes it simple to handle them as a whole field. It works as a helper for Zend_Form and lets you set things like the separator between the text fields, a "format" string and a validator to apply to their fields (in the example code, it's the "digits" validator). Sample code is included to show you how it fits in your form.

Have you ever though about extending mysqli's classes. It's pretty simple to subclass the connection class mysqli. However, subclassing mysqli_result and mysqli_stmt is not so obvious, actually I though that it's even not possible. However, never say never! After discussing mysqli's OO interface for an hour yesterday [...] I found out how one can plug his own classes.

Two code examples are provided - one for extending the mysqli_result and the other extending the mysql_stmt class. You can find more about these and other classes the mysqli extension has to offer in this section of the PHP manual.

Solar's manual has a getting started section that walks you through setting up a basic app, This app extends "Solar_Controller_Page" which handles a lot of the backend work for you. As you get into your project you will find that pretty much every controller you have needs access to some basic structures and information, how can you ensure these are always available?

His example extends the Solar_Controller_Page to provide two model objects automatically to the rest of his application (as protected objects in the base class).

As the GUI of Zend Server is based on the open-source Zend Framework, you can easily extend it. This article demonstrates how to integrate new functionality to Zend Server which makes it possible see the content and some meta information of cached items. For this example I use the Data Cache API from Zend Server, but in combination with the Zend Framework component Zend_Cache and its Zend_Cache_Backend_ZendServer_Disk backend adapter.

He steps through the creation of a new Zend_Cache object and an implementation of the Zend_Cache_Backend_Interface as well as making the new tab for the data to live under in the GUI. The interface is dropped in place and a view and model is added and your end result can look like this.

With the advent of PHP 5.3 adding new methods to an instance of a class at runtime becomes possible with PHP as well, using anonymous functions and a little bit of __call() magic.

He illustrates with a bit of code - defining the base class and using a __call method to catch any undefined method calls. Using this in conjunction with closures makes it possible to call the method internally, avoiding the usual error that could result from setting it like you would a class property.

In order to understand how to extend Zend_Tool, you need to know a few things about its overall structure. The whole of the system was built with extensibility in mind. Each of the major functional parts of the system are abstracted in such a way that its easy to not only extend, but to replace with completely separate implementations. [...] But for our first order of business, we'll demonstrate how to add new commands to the Zend_Tool system.

He dives into the details of the Zend_Tool internals (including the Manifest component, the Provider_Version and the Provider_interface) before getting into the example code of the actual extension. He makes the typical "Hello World" example and shows how, with a simple command line call, you can execute the provider.