The other day I was debugging an error in one of my unit tests, and found it hard to track down because when I ran PHPUnit, it ran all the tests contained in the file where my problem unit test was located. After some Googling and reading the PHPUnit Api Docs, I found that you can specify a test, among other tests, by adding a comment with the @group annotation.

Using this "@group" annotation tells PHPUnit to combine these tests and allows you you specify a "--group" setting on the command line to only run those. He includes some sample code showing how it can be used. This can be very useful for combining results for certain kinds of tests (say, all related to bugfixes) without having to run everything all over again.

One of the powerful features of an IDE like Eclipse is the ability for it to "read" your code and give you some assistance about your API as you type. This could include things like class property or methods names, constants, functions, argument lists, and so on. Eclipse/PDT and ZendStudio do this by parsing a PHP class directly, but they also look at your docblocks and some other special comments where the raw PHP is not enough. This article is a bag of tricks that help you get the most out of code assistance using Eclipse/PDT or Zend Studio in those awkward corners of your code that you might have through previously inaccessible.

Among his tips are things like adding "@var" declarations to help with code completion, type hinting on methods/functions, using the "@property" annotation and using a "this" trick to override what class the IDE sees as the local object. ,/p>]]> Thu, 01 Dec 2011 12:55:32 -0600 http://www.phpdeveloper.org/news/17085 http://www.phpdeveloper.org/news/17085 PHPUnit is one of the most widely used unit testing tools for PHP applications. It comes packed with features, some that are commonly used and some not so much. In a new post to his blog today Volker Dusch looks at one specific feature - the "@covers" annotation you can use in your tests' comments to specify which functionality you're actually testing.

One of the goals of your test suite and the coverage report is to make you trust in your code base and to remove the fear of changing something that needs to be changed. [...] You shouldn't think "Well yes that a 100% but a lot of that just comes from that big integration test and I don't know if the class is really tested!". [...] Thankfully PHPUnit offers a way to drastically increase your confidence in what you actually have tested.

Using the "@covers" annotation on your test method docblocks gives you one more level of confidence in what's being tested and can help make for clearer updating down the road. He also mentions using them to provide extra insight into protected methods in your code and where the test coverage for them really lies.

PHPUnit has lots of advanced features that can be amazingly helpful when that special case comes around. This includes extending the framework itself, making test suites, building static datasets, and the focus of this article: annotations and mocking. Don't worry if you're unsure what either of these are; I'm here to help. I trust by the end that you'll see how these two features can be useful to both you and your tests.

The article starts with annotations showing how they can be used both on the class side to help with test generation and on the test side to help in evaluation (like expectedException). In the mocking section, it shows you how create simple and complex mock objects to replace a sample database query.

The most simplest reason for this is the idea that annotations are markup. They mark (or, to keep the notion, annotate) code as being special or to be treated in some special kind of way, depending on the scenario where the code is used in. [...] From a design point of view this makes it clear why annotations should not contain logic. If annotations contain parts of such logic, it becomes splitted and possibly cluttered throughout different classes.

He goes on to talk about a second reason why he doesn't think they should be considered first-class in an application - it doesn't promote code reuse. For example, if you define them on a method, there's no way to use that method without them. He puts this into the perspective of the Stubbles framework that currently uses them and how he's changed the logic to live in special classes instead. He considers other changes like places annotations can be used and having different annotation classes.

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.

In this episode, Manuel Lemos and Ernani Joppert discuss several unusual site speedup techniques presented in recent articles of the PHPClasses site blog. They also discuss the (non-)inclusion of new PHP features discussed by PHP core developers like having named parameters in function calls and the support of Java-like annotations in PHP code.

To listen you can either use the in-page player, grab it from iTunes or just download the mp3. Complete show notes and transcript are also included in the post.

Annotations are a really helpful feature in present-day development. An annotation is a special form of syntactic metadata that can be added to source code elements such as classes, methods, properties and parameters. They do not affect the program semantic directly, but can be used by tools and libraries to handle such annotated code in a certain way.

He notes that, as of right now, PHP doesn't naively support anything like this but that there are additional libraries that can be used to augment the standard PHP performance and use them (like a feature in PHPUnit with @assert and @test). He also go through several of the other libraries that make it possible including Addendum, FLOW3 and the XP-Framework.

At my company, we typically organize our test case classes into high-level groups such as unit and functional. Method-level group annotations are inconvenient for us because we'd need to annotate every method of every test case class.

He includes an example of their use - commenting a testing class and running it through the phpunit command line tool with a call to the testing group's name.

In Stephan's post:

Porting JavaDoc comments to PHP was one of the best things, that ever happened to to PHP4. But like in Java 4, the DocBlocks in PHP evolved from plain documentation to a feature that adds meta information to classes, methods, properties and variables. IDEs, like Zend Studio, use the @var tag to enable type hinting for method return values, which would not possible without the DocBlock, as PHP is a dynamic languages.

And from Frank:

In part three of his wishlist for PHP 6 Stephan wrote that he would like to see annotations built into PHP 6 directly. I disagree with him about that. Annotations can be done in userland, without any problems. He already gave some examples of projects that accomplished this task. But if you look at them you see that every project has a different solution on how to implement annotations for PHP which leads to the problem that if you use different projects in your own application you have to handle all their ways of treating annotations. Annoying, isn't it?