Singletons are often compared to same class of evil as goto instruction, or more familiar for PHP developers $GLOBALS. This thesis is hard to understand since Singleton is most basic and commonly know pattern. Even if one agrees with arguments, might find hard to eliminate singletons from own code. Giorgio Sironi shows that eliminating singletons is not that hard.
It is actually very simple to eliminate singletons: just force the components to ask for what they need in the constructor or via setters or via inject*() methods, instead of looking up a singleton trough a static method only to obtain a reference. Once this fundamental decoupling is achieved, the hard part is tackling the construction problem: Zend Framework has a big codebase and writing a factory (manual dependency injection) for every use case is not viable. Thus, automatic dependency injection needs to be called upon. There are many xml-configured dependency injection frameworks for php to incorporate, but let’s show a simple example of how they works.
The tutorial was split into two parts. First one presents basic solution for the problem. Second part addresses some problems related to objects having shorter lifetime than application-wide ones.
There has been lots post published about unit testing in Zend Framework recently. Most of them show how to setup simple testing environment and write simple test. In his recent post Giorgi Sironi shows how not to test Zend Framework action controllers.
Yesterday on twitter a discussion started about how to properly design Zend Framework action controllers to allow simplicity of testing, specifically how to inject collaborators in controllers and to avoid breaking the law of Demeter.
Presented real life example seems to be simple and typical. Giorgio explains what is wrong about it and what kind of obstacles from unit testing point of view it creates. The post is not only about how no to test controllers but also about what controllers should and should not do.
Update
Giorgio’s post has its continuation, where he explains why we can drop unit testing controllers and what controllers really do.
Update 2
Giorgio published another follow up to his, as we see controversial, post.
Testing application based on Zend Framework is generally smooth and easy, especially with help of Zend_Test component. Generally, but not always. Testing plugins or other extensions of some Zend Framework components can be tricky. One of such components is Zend_View and it’s helpers.
The empty constructor is the problem in view helper management, since it gets in the way of simple test code when you write view helpers that make use of other view helpers as collaborators. (…) In this design, the view acts as a Service Locator, and we have no idea which helpers could be called by another one: every helper class could depend on everything else. (…) My very-simple-testing solution would be require helpers to specify their collaborators in the constructor or via setters, implementing Dependency Injection. We cannot change the standard Zend Framework architecture, though, but it’s not a framework’s fault. This solution would have required to build a small automatic dependency injection system, which is not in the scope of Zend Framework 1.x (but will be in 2.x as far as I know).
Tricky and problematic does not mean impossible. In his latest post Giorgio Sironi presents his approach to unit testing Zend_View helpers. He explains problem of unit testing view helpers, proposes few solutions and presents the best one for him.
