In this recent post over on DZone.com Giorgio Sironi takes a look at the "clone" feature of PHP - what it is, how it can be used and things to watch out for in its use.

Cloning is an operation consisting in the duplication of a data structure, usually to avoid the aliasing problem of having different code modify the same instance in inconsistent ways. In PHP, cloning can be accomplished in multiple ways - and in some cases it can be avoided altogether.

He talks some about how objects are passed around internally during the PHP execution and how you can tell if a function works with data by reference (from the manual). He then looks at the "clone" keyword and what kinds of things are duplicated from an object when it is used. He briefly touches on the "__clone" magic method for solving the "shallow clone" problem and how, possibly, serializing the object might be a better alternative for reproducing the entire object.

In a new post today Padraic Brady takes a look at unit testing and two of the bad practices that can develop over time when writing your tests - overloading tests with assertions and lazy/shallow tests.

In short, every test you write requires that you setup the test environment, create a scenario for possible failure, add an assertion, and then ensure the source code makes that assertion pass. This requires code - sometimes a lot of code. So adding multiple assertions to each test minimizes the work needed to write tests, since using multiple assertions takes advantage of existing code to avoid writing new stuff to clutter your test classes. It can also help to tackle multiple but related results in the same test.

He gives brief examples of both instances and some of the problems associated with them. Multiple assertions, while nice for fine tuning the results of the testing, can also confuse since, if one assertion fails, the whole test fails too. The other end of the spectrum is a problem too - writing tests that don't do enough to really check the information passed in. These shallow tests can lead to issues down the line if unanticipated data might come along.

Really, its all about finding that "sweet spot" in developing tests - not too much, not too little - and keeping it simple while not missing out on assertions that need to be made.

As the PHP:Impact blog points out there's a new post from Neil Garb talking about the (loose) coupling going on inside the Zend Framework.

One of the Zend Framework's strongest drawing cards, as I see it, is its loosely-coupled structure. The name Zend Framework may be a misnomer, in fact, as ZF is more a set of reusable libraries than an actual application framework. I won't go into detail about the advantages of loose coupling, but a recent discussion on the ZF mailing list prompted me to investigate just how loosely coupled the framework is.

He's created a few graphs to show the extent of the coupling - a directed graph, the density of it and example code showing deep and shallow coupling. Here's his results.