On the Web Technologies blog they've posted a guide to some of the top PHP code quality assurance tools to ensure your codebase is kept neat, clear and clean from any unnecessary complexity.

You’ve got the good approach dear reader: code quality tools are essential to write solid and error-free PHP code. It can help your colleagues detect defects in the codebase and teach them some key concepts.

Don’t forget however that the advises and data they can provide won’t be appropriate everywhere. Your experience and your analysis skills are the one you should trust first.

The tutorial starts of with some of the tooling you'll need to get the system up and running: Composer for package management, terminal access for command execution and editor/IDE integrations (optional, obviously). It then lists out each of the tools and includes installation steps and links to more information:

• PHP-CS-Fixer (PHP Coding Standards Fixer)
• PHPCS (PHP CodeSniffer)
• PHPMD (PHP Mess Detector)
• PHPStan (PHP Static Analysis Tool)
• PHPUnit and the CRAP metric

It also includes a few "bonus" tools that might be useful to track other quality aspects of your code including PhpLoc (lines of code), PHPMND for detecting "magic" numbers and churn-php for evaluating complexity of code based on number of commits. there's several more listed in the full post so be sure to check it out and see how you can integrate them into your development process.

As you write your PHP code, you'll need to verify that everything is working as expected and that the code follows all style and formatting requirements. In this list from the SitePoint PHP blog they give you a list of eight tools you can use to ensure all of these criteria are met.

For shipping quality code, we must have testing in mind while coding (if not doing TDD). However, with the wide range of PHP testing tools out there, it’s hard to make a choice! Exploring PHP is a fun adventure (premium course on that here!) but it’s hard to assemble a toolbelt that’s not too heavy to wear to work!

This popular article will highlight the most popular testing tools and has been updated to reflect the state of QA tools in 2017.

Included in their list are tools like:

• PHPUnit
• Cucumber
• Selenium
• Kahlan
• php_testability

The post ends with a brief look at continuous integration and how they can help execute these tools automatically when code changes or before production builds are deployed, taking most of the burden off of developers to remember.

Andrew Podner has a posted the second part of his series looking at functional testing in PHP applications with Selenum.

In the first post about functional testing, we went through the basics of what functional testing is and how it complements and differs from other types of testing used for software quality assurance. This time, I will spend some time talking about using functional testing in a practical sense to set up a testing suite for a web based software project. [...] Each of these can provide a powerful means of performing automated functional testing and you should select your tool of choice based on what works best for you. I typically find myself using Selenium for functional testing, but again, I would encourage you to look at each available option out there and select the best fit

He walks you through the installation of the Selenium Firefox plugin, some of the basics of its use and how to create and run a simple test. He also looks at a slightly more complex example - filling in a form and validating the resulting page.

Andrew Podner has posted the first part of a new series to his site today. He'll be looking at using functional testing to improve quality of the resulting code and full application.

For this week, I wanted to focus on some different types of automated testing other than unit testing that can help developers build more robust applications and improve both the speed and effectiveness of quality assurance. Specifically, this post is going to focus on functional testing. Functional testing is composed of the tests that you write which are from the user’s point of view. A functional test is used to perform quality assurance on all or part of an application utilizing the user interface as a pathway to the application.

He gives some examples of functional tests like clicking on buttons, trying a login, checking that the contents of the page are correct. He talks some about the purpose of functional testing and how it differs from unit testing. He suggests the metaphor of a race car - the pit crew would be the "unit testers" and the driver would be the "functional tester", saying whether or not all of the parts of the car are working together as they should for the race. In the next part of the series, he'll talk some about the actual software to automate this process.

Michelangelo van Dam has posted the fourth part of his "Quality Assurance in PHP projects" series to his blog today - a continuation of his emphasis on PHPUnit and testing his sample "Tic-Tac-Toe" game.

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.

Michelangelo van Dam is back today with the next part of his "Quality Assurance in PHP Projects" series, the third part of his look at PHPUnit, the popular PHP-based unit testing software.

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.

Michelangelo van Dam has posted the second part of his look at PHPUnit in his "Quality Assurance in PHP Projects" blog post series. This is a continuation from part one.

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.

Michelangelo van Dam continues his "Quality Assurance in PHP projects" series in his latest post, the first of a few, about using PHPUnit to test your application.

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.

As a follow up to his previous post about using DocBlock commenting and phpDocumentor for automatic project documentation generation, Michelangelo van Dam has posted a deeper look at DocBlox, one of his previously mentioned alternatives.

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).

Michelangelo van Dam has posted the latest in his "quality assurance in PHP projects" series today with a look at something that can make your life and documentation easier - PHPDocumentor.

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.