In this recent post on Reddit.com, a developer asks the community about some of his feelings about bugs in his software and his focus on quality:

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

For those either just getting into unit testing your applications (maybe even TDD) or those that are old hat at it and what to figure out a few more tricks of the trade, you should check out this latest post from Chris Hartjes about some of the tools he uses to get the job done.

So how does the Grumpy Programmer write code, TDD style? It starts with using a set of tools that reduce the amount of friction required. First, I do almost all my work from a terminal. [...] Why the terminal? PHPUnit is a CLI application. Yes, many popular editors and IDE's can do things like execute PHPUnit for you, but they are limited in what flexibility they provide.

He also talks about his editor of choice, vim, and some of the plugins he uses in his day to day testing development. This includes tools to handle things like interfacing with git/gists, working with ctags to see the code's structure, working with "surroundings" and the pathogen plugin to make adding other plugins easier. He keeps the code up in one terminal and his testing tool (PHPUnit or other) accessible in a second, making it a simple matter of switching to write the test then the functionality to make it pass.

If there is a lesson to be learned from this, it's to make sure that every tool that you use reduces the friction that is generated when building your application using TDD.

In this new post to his blog Shashikant Jagtap talks about a new extension for Behat (the BDD testing tool) that makes working with Mink even easier - MinkExtension.

'MinkExtension' has been just released which has additional services for Behat. This extension has 'Mink' instance for your 'FeatureContext' and 'SubContext'. UI testers would be happy now, as they don't need to create Mink instance every time in order to use Mink API's.

He points you to an example application you can use to follow along. He includes the commands needed to install the dependencies via Composer and get this extension working (note: it requires PHP 5.4 for some of the traits stuff. If you don't want to use that, comment out the "TraitedFeatureContext.php" file). Also included are the commands to execute the tests with a Selenium server and a list of a few handy new things this extension enables.

On his site Marcelo Gornstein has published a new guide to getting a basic automated continuous integration server set up with Jenkins and Phing.

This article is about how to use Phing in your projects, so a continuous integration server (in this case artifacts for your php application (deployment artifacts, documentation, code metrics, etc). I'll try to show why this will make your life easier when developing or auditing code, generating releases and deploying new versions, trace bugs, etc. All with just a handful of phing tasks.

He introduces the Phing tool and explains how it makes automating the steps of your process simpler, relating it to the Apache Ant tool for those familiar with it. He links to several of the resources used in the process including PHPLoc, DocBlox and the code for the article itself. He outlines the process and, complete with a screenshot of the final result, shows you how to get everything configured and running smoothly.

In this new post to DZone.com, Giorgio Sironi talks about a method of testing that's non-invasive when you're in a chicken-and-egg kind of situation:

The legacy code dilemma, however, is always present: you can't refactor the code before putting up some tests on it to avoid regressions and putting your application offline. At the same time, you can't easily unit test the code until some refactoring is introduced.

He suggests making copies of some files to allow you to make small changes where needed to "mock" resources in the application to prevent it from accessing the actual data sources. His method fakes HTTP requests to the script and uses the copy of the script as an internal resource. Don't worry, code is included showing how its done - a basic "ForumPosting" class that includes the needed file and wraps the output in a buffer.

Earlier this month Shashikant Jagtap wrote up a post about a powerful combination in testing your applications - a "rockstar" combo of PHPUnit + Behat/Mink + Page Object to give you a great foundation for BDD (behavior-driven) testing.

Last month, we had discussion about implementing page object pattern in Behat/Mink framework at London Behat Users meetup. Page object pattern is a cool way to make tests maintainable, reusable and readable. Everyone was interested to know more about Page Object Pattern. In this short tutorial, we will implement Mink and PHPUnit combination for functional testing. Mink and PHPUnit combined with Pageness (Page Object) can be used for maintainable and readable tests.

He assumes that you might not have all the tools needed installed, so he walks you through the setup/install of PHPUnit, the PHPUnit-Mink framework and both the Sahi and Selenium drivers. He includes a basic directory structure for the testing and shows how to create some Page Object classes that extend the default TestCase and make calling the remote resource simple. He also includes the steps needed to execute the tests via PHPUnit.

As mentioned on the main PHP.net site, the latest Release Candidate for the PHP 5.4.x series is now available for testing:

This is the 2nd release candidate. The release candidate phase is intended as a period of bug fixing prior to the stable release. The release candidate fixes a critical issue when using the internal classes in multiple threads. A complete list of changes since the last release candidate can be found in the NEWS file.

The source packages can be downloaded from the main QA site and the Windows binary packages from the Windows QA site.

Sebastian Göttschkes has a new post to his blog about a set of abstract base testing classes he's developed to help with the functional, unit and validation testing of his Symfony2-based applications.

So, when developing with symfony2, I rely on my tests. They are my safety net and without them, I get a little nervous after every change. Does everything work? Did I forget anything? So I developed some classes which I extend. They work on top of PHPUnit and the symfony2 WebTestCase. The classes are used by my different types of Tests: UnitTests, ValidationTests, FunctionalTests (as well as IntegrationTests).

Code for each type of testing base class is included in the post showing how he extends the based PHPUnit test case for unit testing and the Symfony WebTestCase for validation and functional testing. Each one of the classes are ready to use and give you some handy helper methods too.

In a new post to his blog Chris Hartjes, promoter of all things testing, looks a a method for testing constructors - an effective way to validate the things that happen when your objects are generated.

If you have a PHP application that makes heavy use of objects (which is probably 95% of you reading this) then you will have objects with constructor methods in them. It is also very likely that there is some stuff going on in those constructors. So how do you test things like this?

He includes a sample constructor that creates a container, pulls out some configuration values and reassigns them to class properties. He first tests that these properties have been set correctly by mocking out the object and overriding the configuration settings in the (dependency injection) container.

On PHPMaster.com today there's a new article with some thoughts of a pragmatic tester - some thoughts from Michael Bodnarchuk about both unit and functional testing.

Here's how it usually plays out: the developer thinks, "I need to do unit tests, and I should use PHPUnit because it's a standard. I don't know much about it, though." Then he visits the PHPUnit site and reads the first chapter of the documentation, then the second, then the third… and is left scratching his head.

[...] Maybe something similar happened to you. Maybe not. But you really should know what to test and how to test it. Such knowledge comes from experience, so in this article I'll share some of my experience with unit testing.

The article's not so much an introduction to unit testing as it is some of the experiences he's had around testing his applications both at the code level and from a functional perspective. He also mentions some alternatives to the standard PHPUnit testing like Atoum and EnhancePHP.