In this new post to thePHP.cc blog Sebastian Bergmann (creator of the PHPUnit unit testing tool) questions of some the current "best practices" involved in using the tool. More specifically he looks at the handling for expected exceptions and proposes a new practice to use going forward.

It is important to keep in mind that best practices for a tool such as PHPUnit are not set in stone. They rather evolve over time and have to be adapted to changes in PHP, for instance. Recently I was involved in a discussion that questioned the current best practice for testing exceptions. That discussion resulted in changes in PHPUnit 5.2 that I would like to explain in this article.

He talks about the currently widely used practice of the @expectedException annotation to define when an exception should be thrown from the code inside the unit test. Sebastian talks about the evolution of this into other annotations around the code and message returned from the exception too. He then proposes the new best practice as a result of some discussion around the annotation method: returning to the use of the setExpectedException method. He provides some reasoning behind the switch including the timing of the exception being thrown (not just "any time" but a more specific time).

Larry Garfield has posted some of his thoughts on return values and reminds you about consistent return types, regardless of the result.

Earlier today, I posted a brief tweet (isn't that redundant?) about return values in PHP (or really, any language). Originally it was about return values from functions (such an exciting topic, I know), but it ended up generating a fair bit of lively conversation, as well as a patch against Drupal 8. So lively, in fact, that I think it deserves more than 140 characters.

He proposes a new rule of thumb: "If your function returns a collection, its null value return must also be a collection." A more broad version of this might be: "make your return types consistent." It's all about predictability and the contracts you have between different parts of your code. If a user calls your method expecting to be able to loop over the results, they'll be disappointed with a "false". He talks some about using and throwing exceptions more effectively for error handling and answers several "but wait..." arguments for his return strategy.