Chris Hartjes (aka the "Grumpy Programmer") has written a second book that aims to teach you even more about writing testable applications. Where his first book taught the basics of making apps testable, this new book - The Grumpy Programmer's PHPUnit Cookbook provides code examples showing how to solve some of the common problems you'll come across when testing your applications.

You know you need something better, but time just doesn't seem to be on your side. Making things "right" is costly and you need to deliver working code NOW. Tests would be great but there are real deadlines to meet. You can't stop development and churn away for hours just to add tests around what you know already works. [...] No longer would you dread the bug reports. You'd happily make changes knowing that your safety net is there. You'd try out new features guiding yourself with tests.

The book covers some more advanced topics than you might have seen in the previous book including data providers, test doubles, faking test data (or using external sources) and writing tests for APIs, databases and exceptions. If this sounds interesting to you, you can pick up your own copy of the book on his site (or try out the sample first).

On PHPMaster.com today there's a new tutorial posted about improving on the PHPUnit database testing extension to allow you do other non-query (select) operations - the "C" and "UD" in the typical "CRUD".

In a previous article I discussed how you can create more robust code that queries your relational database through automated testing. But, as you know, querying is just one part of the picture. There are still other database operations, namely create, update, and delete. Just like retrieval, they too should be tested. I'll be exploring the other features of PHPUnit's Database Extensions in this article while building on your knowledge of database testing in PHP.

He helps you get the test environment, complete with the base SQL structure, and the data to test against (and XML structure). They include the sample code to create the test itself and the results when the tests are executed.

Volker Dusch has a new post reminding us about what the "unit" part of "unit testing" means - small chunks of testable parts in an application.

What does the word UNIT in unit testing stand for? Think of an answer and read on! So? Did you say "A method! Because we test methods!"? If so let me offer another perspective.

He suggests that, rather than about just the methods in the class, it's more about testing the "observable behaviors" of the class. That is, anything that you could publicly use the class for and have something happen. He gives examples of this shift in focus - calling setValue and evaluating the result versus just calling the class property itself (then calling the method). He also includes a bit about testing behaviors - what happens when my script does [this] and how does that effect the overall class.

When your tests fail but the class "still works" and you need to "fix the tests" the your tests are worth a lot less as they don't really give you that cozy safety net that they should provide you with.

On the Zend Developer Zone there's a new article from Keith Casey looking at some of the "best practices" when it comes to writing unit tests for your applications.

If we are starting from absolutely nothing, building tests as we go is a near-trivial process. [...] Unfortunately, most of us don't have this situation. We walk into a project with documentation ranging from non-existent to seemingly-useful-but-really-out-of-date, and hundreds of thousands of lines of code, and the coding standards and practices of every developer that has come before us. In this situations, the above Unit Test example is almost mocking us. We can't start that simply! Or can we?

He walks through some of the steps he and another project lead took to start their trip into testing - finding the most problematic bits of code first (based on bugs in the tracker) and testing them, figuring out how to test rapidly changing code, finding common code used in several places and testing that and

On his blog today, Jani Hartikainen has posted the third part of his series looking at unit testing in PHP applications.

Now that you know what unit testing is and how to write and run tests, it's time to look at writing tests in more depth. Today we'll take an example class and write tests for it. We'll also introduce some common testing methodologies.

He creates the sample test (this one), makes a sample testing class for it and looks at the difference between testing code and testing behavior.

Highlights of this new release include software metrics, project mess detection, copy-and-paste detection, improvements to SeleniumTestCase for better integration with Selenium RC, data providers for test cases, and grouping of tests.

Another mentor for another Google Summer of Code project has been announced and Sebastian Bergmann will be mentoring Mike Lewis as he adds mutation testing for PHPUnit.

Sebastian quotes a definition of "mutation testing" as:

Mutation Testing, or Automated Error Seeding, is an approach where the testing tool makes some change to the tested code, runs the tests, and if the tests pass displays a message saying what it changed.

The key difference is that it makes it easier to run a series of tests rather than just one at a time, aiding in more complex testing abilities. Check out this page on the PHPUnit site for more information.