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.

Test-driven development is generally regarded as a good move: it should result in simple decoupled design, your tests tend to cover behaviour not methods, and far fewer bugs. However, just getting unit tests in on a real, commercial project is hard - switching to TDD is even harder. [...] So, instead of beating ourselves up about not being perfect let's look at an interactive approach to adopting TDD principles. We'll look at tactics for selling TDD to your client, boss and colleagues. This talk will also cover methods for making TDD easier for you by showing you what tools you can use to integrate it into your development environment.

You can listen to this new session recording through the in-page player, by downloading the mp3 or by subscribing to their feed.

It may seem strange but I'd like to start out with giving my opinion on this book: It is brilliant! If you don't like reading my post you at least know what you should do next: buy the friggin' book. The book offers some theory concerning agile development, (unit-)testing and code quality but its killer feature is the almost 200 page long example of developing an application the TDD way! In the rest of this post I will shortly highlight different parts of the books and stuff I enjoyed or learned from it.

He breaks up the review in to a few different parts - the process of test-driven development, his "first real lesson", their working example and a section about the more advanced topic of sustainable test driven development.

You know it; I know it. We should be testing our code more than we do. Part of the reason we don't, I think, is that we don't know exactly how. Well, I'm getting rid of that excuse today: I'm teaching you to test your PHP with the EnhancePHP framework.

He shows you how to download it, get it installed and creates a simple structure to do some TDD (Test-Driven Development) with it. His tests check three things - valid email addresses, username restrictions and phone number formatting. He also includes a look at creating mocks/stubs for a "scoreboard" example.

You can find out more about the EnhancePHP framework on its github page.

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.

Today we're going to create a library to use a simple RESTfull API for a great project called Gzaas. [...] Ok. The API is a simple RESTfull API, so we can use it with a simple curl interface. A few lines of PHP and it will run smoothly. But Gzaas is cool so we're going to create a cool interface too. This days I'm involved into TDD world, so we're going to create the API wrapper using TDD. Let's start.

He starts with his tests, defining checks for fonts, patterns and styles and moves into a sample call that sets configuration options for background color, shadows and visibility. You can find out more about what the service has to offer by reading the documentation and the client Gonzalo has written for it in github.

I couldn't find any recent surveys looking into the percentage of software development teams that make use of TDD, but i'd hazard a guess that it's probably not as high as it perhaps should be. I think there are a number of reasons for this, but it's primarily all about the people. The technologies are here, you've just got to start using them - which begins by understanding why they should be used. [...] There are a number of test frameworks for PHP, the biggest of which are probably PHPUnit and SimpleTest. My preference is for PHPUnit, which is the one I'll be using here.

He walks you through the basics first - installation of PHPUnit from its PEAR channel and setting up some basics tests. From there he moves into the TDD-ness stage, creating a sample class to test the getting and setting of values from a configuration class. He also provides the class that's something like your end result should be.

Few tasks are more tedious and frustrating than debugging a Web application. [...] Fortunately, PHP developers have a number of powerful debugging solutions at their disposal. Whether you're merely inspecting array contents or attempting to determine the status of an Ajax-driven POST response, these four solutions are guaranteed to have an immediate impact on your productivity.

His four solutions involve changing the error reporting level on your development environment higher than production to catch issues that might slip through unnoticed, using XDebug, integrating FirePHP and using test-driven development to be sure things work from the outset.