On the QaFoo blog there's a new post sharing a method for testing the untestable - file upload handling in your application.

A long time ago I wrote a blog post about Testing file uploads with PHP where I have used a CGI PHP binary and the PHP Testing Framework (short PHPT), which is still used to test PHP itself and PHP extensions.

Since the whole topic appears to be still up-to-date, I would like to show a different approach how to test a fileupload in PHP in this post. This time we will use PHP's namespaces instead of a special PHP version to test code that utilizes internal functions like is_uploaded_file() or move_uploaded_file().

They update the previous method to use the namespacing built in to PHP to "trick" the test into using a method from a local namespace first. The provide the code they'll be testing and a unit test to try and evaluate its result. The tutorial then shows how to use the namespaces to define is_uploaded_file and move_uploaded_file functions that override the defaults. These are used instead of the base level PHP ones making it easier to test the results of the mocked functions rather than the originals.

In this new post to his site Brandon Savage looks at the "myth of the untestable controller" and gives some tips to help resolve it.

It’s a persistent statement: controllers should have as little code as possible because they’re difficult, nay impossible, to test. Developers should force most of their code into the models instead, where business, validation and other logic can take place. [...] But this is not true. Controllers are no more or less testable than any other kind of code. What’s more, the fact that people believe controllers are largely untestable is an excuse for writing untestable code, not a valid design decision.

He talks briefly about where the myth might have come from (Zend Framework v1, with it's difficult to test controllers) and a note that, really, controllers are as testable as you want them to be. He give three things that could help make them easier to test:

• Using dependency injection/inversion methods
• Refactoring to use the Abstract Factory design pattern
• Using anonymous functions/closures over plain configuration settings