Stuart Herbert has two new posts to his blog showing how to use the ContractLib tool he's created to define programming "contracts". In the first he shows some sample usage of the tool and in the second he compares the functionality of ContractLib's features and PHP's own "assert" method.

ContractLib is a simple-to-use PHP component for easily enforcing programming contracts throughout your PHP components. These programming contracts can go a long way to helping you, and the users of your components, develop more robust code.

In his example tests he shows how to set a pre-condition on a method's input ensuring that it will always be the correct datatype (array). In his comparison with PHP's "assert", he lists out some of the features that either one has and notes that ContractLib allows you to be much more flexible with your checking than just simple statements.

In a recent post to the "PHP and Me" blog they look at how to type less $this in your PHPUnit tests using some handy tricks and a bit of custom code.

Lately I've been writing a few tests (using PHPUnit), and when you do there's one thing you end up doing a lot, which is typing $this-> whenever you need to do pretty much anything. It's not that bad (and PHP can be quite verbose itself) but it can become a bit of a bore I guess, especially after a while. [...] Those were valid points [about the global testing functions added to PHPUnit], and for a while that feature was even temporarily removed. So.. now what? Back to typing all those $this-> over & over again? Maybe not.

The post shows how to use the included functions to remove the "$this" in something like "$this->assertTrue()" or, to reduce things even more and not pollute the global namespace, a different approach by extending Assert. A few code examples are included as well as the class that extends the normal Assert functionality PHPUnit provides. It allows for the more flexible short-hand function calls to automatically be mapped back to their "more correct" versions.

On the Web Builder Zone (part of DZone) Giorgio Sironi has a new article talking about new features in the latest release of PHPUnit including one of his own introduction - the MockBuilder to make mocking in tests simpler.

The official release of PHPUnit 3.5 is now available for PEAR installation, after a long beta period. PHPUnit 3.5 provides many new features such as a bunch of new assertions methods and annotations, and a little but very useful contribution of mine: the MockBuilder. [...] As you may know, the 3.4 Api contains a getMock() method with 7 arguments. Since some of this arguments are booleans, a call to getMock() can get very obscure if you don't memorize the meaning of all the 7 arguments. [...] The Builder creational pattern is a small layer of abstraction over the instantation process, that [...] gives you a clear Api.

He includes a few examples of both the "getMock" function call and its "getMockBuilder" relation. He also includes a full sample class that shows off some of the other new improvements to PHPUnit like new assertions on variables and object attributes, the "instanceof" checks and the MockBuilder once again.

The PHP Developer Blog has a quick post for the unit testers out there on how to work with exception handling in your tests.

When unit testing, you'd also want to test whether your application throws Exceptions as expected (the following examples are based on SimpleTest). Assumption for the examples is, that we have a method that expects an integer as parameter.

Putting the assertion inside of the catch block won't work correctly since it wouldn't happen unless an exception is thrown. Instead he recommends putting it right after the exception try/catch and check to see if the exception variable is a type of 'Exception' (with another potential solution of adding in a check for an 'InvalidArgumentException').

In looking to test his fputscsv functionality, David Otton found a simple way to measure its performance by using streams.

Then I realised I could use PHP's (fairly) new IO streams to dump the function's output to a temporary buffer, and read it back in for comparison. Not perfect, but it removes concerns about file mutexes, permissions, unique filenames, etc. and speeds up the tests, as they never touch disc.

He uses a custom stream and points it to php://memory to store and read the data from. Code is included in the post as well as example usage. It runs an assert that the value pushed into another memory chunk is the same as the first one (ensuring that the results of his fputcsv calls are valid).

Following up on the start of his port of the Hamcrest (a library of "matchers") functionality over to PHP, Sebastian Bergmann has posted the getting started guide to show you how to use it with the popular PHPUnit unit testing software.

There are a number of situations where matchers are invaluble, such as UI validation, or data filtering, but it is in the area of writing flexible tests that matchers are most commonly used.

His example that checks to see if one object is equal to another object. The Hamcrest matcher allows for a "assertThat" method making it easier to create and use pre-existing unit testing assertions.

He also includes a list of some of the most common matchers broken up into groups of core, logical, object, number and text.

Tony Freixas has posted a new article covering his thoughts on high-performance debugging with PHP5:

In this article, I will show you how to use PHP 5 input filters to support debug, trace and assert statements so that a one-line change disables these statements and restores your script to full production performance.

He makes a custom solution, a simple method for just outputting simple debug statements via his own custom debugging classes - thDebug, theTrace and thAssert. He wraps all of these in a thDebugManager class to make them all play nice together.

With these in place, he moves on to the real key to the debugger, using the input filter extension that comes with PHP5. He makes a thAbstractStreamFilter abstract class to base the filtering on and, using this interface, makes his thDebugFilter class to handle the various debugging outputs. He uses the __autoload functionality to load it correctly into each page that needs it.