No one has told me this and I don't need them too. I feel like one bug that has a negative impact on the user experience is too many bugs. I've been programming for over 5 years professionally and I still introduce bugs into my code. [...] I don't like the expectation that I (and maybe others have) that my code must be perfect when I am not perfect. I don't like the fact that it only takes one mistake to affect so many people. [...] I'm wondering if others on here have every felt this way. What have you done about it?

Suggestions in the comments talk about everything from dealing with the apparent burnout the developer is facing, a reminder that no code is bug free and some recommendations of testing and bug tracking to help make the quality of the code better (and give visibility into the level of work being done).

A study from Coverity claims that the source code of Open Source projects such as PHP has a low defect rate. Meanwhile, a few weeks ago, the security expert Stefan Esser claims that PHP source security bug prevention has a lot to be desired because PHP core developers do not have the habit of using source code auditing tools to prevent security bugs. The matter of the PHP source code quality and security bug prevention was one of the main topics discussed by Manuel Lemos and Ernani Joppert in episode 21 of the Lately in PHP podcast.

You can listen to this latest episode either via the in-page player or by downloading the mp3 directly. You can also subscribe to their feed to get this episode automatically (and past/future ones too).

From time to time I see bugs in the code and I start thinking "really? is it possible that no one noticed that bug before? am i the first person to see this code?". I thought it might be worth writing a little post on what helps me to deal with bugs and software quality in general and what are the common pitfalls in developer's thought process. Although it is not a very extensive post i hope it may inspire some developers to try new approaches.

Other topics he offers for consideration involve the fact that bugs will never fix themselves (they might disappear in a refactor though), that the bug is almost never in the language/data source's code and how automated (unit) testing can help to find new bugs before they're released to the users.

Anyone who has used PHP for a while knows that it has its ugly parts. Recently I've seen a whole swathe of PHP-bashing articles and that would fine if they were they are making a valid point, but some of it has just been - as I tweeted recently - "absolute drivel".

He directly refutes some of the points made in that article, points out a newer post from the same author (which misses some points as well) and finishes it off with a look at why he "still" uses PHP versus something like Closure or NodeJS for his development.

Despite known flaws and imperfections I continue to use PHP as my primary language because during all the time I spend worrying about which technology is the neatest, coolest or shiniest I could have built a new application to sell or finished another client site.

Be sure to check out the comments for some other thoughts about the language (and Phil's responses).

OpenSource is an amazing phenomena, but how safe open-source projects are? Would commercial project be safer over the community-supported project? Frameworks can't exist without their core team and In this article I look at how different PHP frameworks are supporting their core developers.

He talks briefly about the need for a good, solid group of core developers on a framework (or really any product) to provide a stable foundation if a product was created with it. Four projects are mentioned - Zend Framework, CodeIgniter, Symfony and Agile Toolkit - and why, because of the backing they have from a company and a large group of developers (and contributors) they're not "yet another framework" that'll disappear over time.

Making new frameworks is fun, however, if you share framework with others, be responsible about the support. Make realistic goals and try to have a plan for a next few years. If you are the author, think who will support the community when you decide to move on.

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