In parts one, two and three we focussed on writing tests for a game of tic-tac-toe, with in parts two and three we optimized our tests so they focus on the functionality of the individual parts Grid and Player, with a collection class Players to handle Player objects.

In this fourth part he focuses on the rules for playing the game and the unit tests to validate the correct flow. He covers one of his tests before, looking at the "can be played" validation for identical symbols. He modifies this to use a provider that gives the test the set of data to work from with varying symbols. He writes additional tests to be sure the game "stops after winning" and that it has a winner/which player is the winner. You can find the full game source (complete with these tests) on his github account.

Time for the third part on unit testing with phpunit in my Quality Assurance on PHP projects series. In part one we started writing unit tests for a simple game of tic-tac-toe. In part two we started converting our unit tests into actual code and moved our general unit test code for grids into a Grid focussed unit test. In this part, we're looking at how we can optimize the tests for our players.

He digs deeper into the TicTacToe application and focuses first on the single-player functionality, checking the symbol for the current player (an "X" or "O") and throwing exceptions in the code when things aren't right. He also shows the tests for checking on "more than one player" and "cannot add more than two players" scenarios. Full code for the Player class and tests are included.

I hope everyone enjoyed my first article on unit testing with phpunit where I started writing a few tests that would guide us building our little game of tictactoe. Today I'm going start with turning these tests into working code and adjusting our tests to have a clear separation of responsibility. Since we already know what the code should produce, we only have to work out the details.

He picks up where he left off on his "tic-tac-toe" example by defining some of the classes that will be needed to fulfill the tests and a sample test to check the generated grid's contents. He includes the Grid class that will do the job (full code included) and a full test case class that runs his example with checks on testGameGridIsSetAtStart, testGridCanPositionASymbol, testGridHasThreeSymbolsInARow and testGridHasThreeSymbolsInAColumn, some with their own data providers.

Of all tools available for improving quality assurance, there's one tool that is the core tool you have to master: PHPUnit. PHPUnit is a complete testing framework crafted by Sebastian Bergmann (@s_bergmann), who ported existing xUnit frameworks to PHP. And with this testing framework you're able to test your functionality in an automated way before you push code into production.

Michelangelo walks you through the installation (via the PEAR installer), creating a phpunit.xml configuration file and making a basic bootstrapper to define some paths and environments. To make the tests a bit more relevant than just pseudo-test examples, he's created a set of tests based around a tic-tac-toe application in a test-driven design fashion (tests first, then code). In this first part he sets up some of his assertions in the tests, but you'll have to wait until part 2 for the code that will make them pass.

First of all, thank you all for the enormous feedback I got on my latest article on documentation of code. I got a lot of comments on the usage of PHPDocumentor. [...] I have to agree that [there are reasons] valid enough to step away from PHPDocumentor as a tool for documentation purposes and look for a better alternative. So I've investigated one tool most people have commented on or tweet-ed/facebook-ed/g+-ed on: DocBlox.

He touches on the installation of the tool and mentions this tutorial from Matthew Weier O'Phinney that guided him through the setup and use of DocBlox. He rand a few tests comparing phpDocumentor and DocBlox for the documentation generate and DocBlox came out on top when it came to runtime (and memory usage).

Unfortunately I've come across too many lines of code that were just lines of code, no comments or annotations provided. So, in best cases I could guess the types and parameters, but in many it was too obfuscated. I already talked about usage of a code sniffer like PHP_CodeSniffer in my previous post where you can validate the usage of comments in the code. But forcing developers (using a pre-commit checker) into writing documentation with their code is not really a good thing.

He suggests using something like PHPDocumetor (there's other PHPDoc parsers including DocBlox and Doxygen out there) to automatically generate documentation for your code based on its comments, giving your developers easier web-based access to the contents. He includes some sample docblocks for a class/method and gives an example command line call to build docs based on a project. A screencast and screenshot of the generated site shows the results of the run.

PHP_CodeSniffer is probably the most convenient tool out there to analyze your source code and to verify it complies to company policies. Although it's debatable why source code should follow strict guidelines, it's only a matter of time before you discover yourself that it pays off to have a code base that appears to be written by one developer.

He talks about how it works to keep every brace in the right place and format the same through out all of your files. He also mentions that its standards are flexible and can be modified as you might see fit. He looks at the installation process (both manual and through the PEAR installer) and how to use it to analyze your codebase. He's even included a short screencast in the post so you can see the results first-hand.

Quality Assurance has become an increasing important part of web application development, especially with PHP applications. [...] Luckily there are a lot of tools available that allows you to increase quality of these web applications, and the best part is they are all based on PHP! Let's have a quick look at what tools are interesting to start improving quality assurance on your PHP projects.

The first tool, PHPLint, helps you validate code against syntax errors and is built into the command-line PHP you already have. He describes its use, both on the command-line and in a pre-commit hook on his git repository

For more PHP QA-related information, he also points out the book from Sebastian Bergmann and Stefan Priebsch as a good reference too.

The German Edition of the PHP Quality Assurance book started shipping. Stefan and I, as well as all our contributing authors, are very happy about this.

The rest of the post describes the book and the case studies that make it up to give you a good overall view of what can be done to help ensure the quality of your code. It will give you some base knowledge of PHP test applications, shows practical results from testing and talks a bit about the current state of quality assurance testing in the online world.

If you're not a German-speaker (or reader, for that matter), keep an eye out for the English edition coming in December 2010!

Some of the most important tools for quality assurance in PHP projects are PHP_Depend and PhpUnderControl. In the future Qafoo - passion for software quality will provide support for both.

He talks a bit about each tool and how they should be used to find and treat a lot of the issues that could come up in your application development. Since the author of the PHP_Depend tool, Manuel Pichler, works for the company, they'll be supporting it as well as offering services for integrating it into your workflow.