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 Zend Framework can be very tricky. The team tries to make framework based applications as much testable as possible, but there are still parts of Zend Framework’s written the way it’s hard to test code based on it. Recently Georgio Sironi was writing about testing view helpers. Today Federico Cargnelutti writes about testing action controllers using mocks.
Unit testing controllers independently has a number of advantages:
- You can develop controllers test-first (TDD).
- It allows you to develop and test all of your controller code before developing any of the view scripts.
- It helps you quickly identify problems in the controller, rather than problems in one of the combination of Model, View and Controller.
What is very interesting about Federico’s post, is that he not only shows example test, but also points reader to some framework’s known issues preventing developers to test particular things. Naturally solution for mention issues is also provided.
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.
