Quality Assurance in PHP Projects

This is an abstract for a chapter from a book on Quality Assurance in PHP Projects.

One of Zend Framework's key strengths and differentiators in the crowded PHP framework arena is its offering of web service consumer components. As of version 1.8.0, these include offerings for Adobe AMF, Akismet, Amazon (including EC2 and S3 support), AudioScrobbler from last.fm, Del.icio.us, Flickr, Google's GData services, Nirvanix, ReCaptcha, Simpy, SlideShare, StrikeIron, Technorati, Twitter, and Yahoo! -- and more are planned or under development.

Offering components to interact with web services is relatively trivial -- but testing them offers a very different story. For continuous integration purposes, it is typically better not to test against live services as this introduces network latency, and thus slows the testbed. Additionally, many services have API call limits, and automated test suites could easily rise far above these limits. There are also concerns about keeping sensitive API keys or credentials in the repository; some services are paid services, and such information would present a breach of security or contracts.

Over time, the Zend Framework team and contributors have developed a set of practices to address these issues that range from mocking the request and response payloads to offering different tests when credentials are provided via configuration. These practices can lead to well-tested service-oriented components and ensure that the end user experience is as documented.

Matthew Weier O'Phinney works for Zend Technologies Ltd. and is the Project Lead for the Zend Framework.

This is an abstract for a chapter from a book on Quality Assurance in PHP Projects.

In this case study, we will talk about how the Symfony framework itself is tested, but also about the tools the framework provides to ease testing the customer applications.

Although developers are well educated now about tests, it is still the most neglected part of a web development process. Most developers still think they cannot afford writing tests because it takes too much time. The Symfony framework tries to ease the creation of both unit tests and functional tests with a unique and simple approach. For instance, functional tests are done by simulating a browser experience, but with the possibility to introspect all internal objects between each request. It is also possible to validate the generated content easily and precisely thanks to CSS3 selectors.

Testing the framework itself also proved to be quite challenging, and we learned it the hard way: from code that is too coupled to be tested thoroughly, to the usage of design patterns like the Singleton. Over the years, the Symfony framework quickly evolved from our testing experience, and now provides a well decoupled, but cohesive set of components. For Symfony 2, the introduction of a Dependency Injection container will be of great help to ease the testing process even more.

Fabien Potencier is the CEO of Sensio and the lead developer of Symfony.

This is an abstract for a chapter from a book on Quality Assurance in PHP Projects.

When Kasper Skårhøj wrote the first lines of PHP code laying the foundation for the TYPO3 CMS in 1998, he had not the slightest idea that a big part of the code he wrote would still be actively used ten years later. Adding the 3700 extensions contributed by an ever growing developer community resulted in an impressive amount of code - of varying quality.

Without surprise it soon became a challenge to assure a high quality and secure product. While the core developers were eager to add new features, the holy cow of backward compatibility was lurking at the next corner, waiting to be fed. The result is a feature-rich and solid but equally monolithic and complex pile of code that is, at best, hard to test. As a consequence we decided to rewrite TYPO3 from scratch.

In this case study we will share our experience with the technical and organisational techniques we have chosen for the development of TYPO3 version 5 and its foundation, the FLOW3 framework. It explains our pedantic pursuit of clean code, outlines our commit and coding guidelines and gives answers to tricky situations you face while writing and maintaining (true) unit tests. Finally we demonstrate how a clean architecture can help you tackling the complexity of your application.

Robert Lemke and Karsten Dambekalns are core developers of both TYPO3 and FLOW3.

A few recipes for writing good unit tests that are part of this case study are demonstrated in the "Delicious Test Recipes" episode of Robert Lemke's podcast.

This is an abstract for a chapter from a book on Quality Assurance in PHP Projects.

The Graph component from the eZ Components project provides an easy to use and extensible library for creating graphical charts. In the eZ Components project we aim to develop test-driven, which resulted in two challenges developing this library.

The output generated by a Graph component is an image, which in most cases is binary-encoded data. Expectations are really hard to create by hand, it is only feasible to create functional tests replaying once created data. The actual image is generated by external libraries such as ext/gd. These external libraries may change their exact output at any time, or even between two runs with the same version of the library. Comparisons of the generated images need to respect that and implement special assertions for the given type of binary data.

Testing the created binary data has proven to be prone to errors. Since the actual image generation has been abstracted away, we are able to use of different image creation mechanisms. Thanks to the support for mock objects in PHPUnit, all calls to the driver layer can be checked for correctness without actually generating images.

Kore Nordmann is an active member of the PHP community and works for eZ Systems on the eZ Components.

This is an abstract for a chapter from a book on Quality Assurance in PHP Projects.

The eZ Components project was started with the goal to create a high-quality set of independent building blocks for PHP 5 based application development. Making extensive use of unit tests and sticking to strict development and documentation standards were defined as the basic methodology. One of the biggest challenges in terms of testing and quality assurance so far was the eZ Webdav component.

The eZ Webdav component is intended to provide a modular WebDAV server to be embedded in any kind of web application. Its architecture is built to be as customizable and extensible as possible, while it tries on the other hand to compensate the weaknesses of the RFC and common WebDAV clients.

Testing a server is a challenge in general. Testing the WebDAV component brought us to the limit of unit testing and forced us to find new ways of using PHPUnit to ensure code quality and to obviate regressions. Unavoidable deep code dependencies in some parts of the server enforced the extensive use of mock objects to stick to the unit test paradigm. In some areas, like avoiding regressions in the adjusted behavior against special clients, unit testing was even impossible. For this reason, special record/playback-based tests were created and implemented using PHPUnit.

Tobias Schlitt is an active member of the PHP community and works for eZ Systems on the eZ Components.