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.