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).

Chance Gracia came across an interesting feature/bug when writing up unit tests for his application with PHPUnit. He was throwing an exception from a mock object and based on his annotation the exception is caught no matter the type.

Anyone who has worked with PHPUnit has most likely worked with expected exceptions and mock objects. The nice thing about working with expected exceptions is that we have access to a handy @expectedException annotation. I've gotten into the habit of using this for exceptions my fixtures should throw but also for when I'm using a mock object to verify a method call.

Some sample code is included to show his problem - a mock object is created for the "foo" class and a test to see if an Exception type is thrown is included on it. The problem is that the exception thrown isn't of type Exception, but of type "foo_exception" and the @expectedException annotation tells it to look for the Exception type. Because of this unpredictable behavior, he suggests not using annotations for these sort of tests or it could lead to false positives.