Code is Lyric

Nach längerer Zeit mal wieder ein Eintrag zu PHPUnit in meiner losen Reihe zum Thema. Diesmal mit einem Beitrag, wie man mit den verbreiteten Unittests auf Ausnahmen testet.

Will man bei einem Unittest auf eine ausgelöste Exception testen, war man bisher gezwungen seine Testklasse von PHPUnit_Extension_ExceptionTest abzuleiten. Mit der Version 3.2.0 wurde diese Funktionalität in die Standardklasse gemerged, also in PHPUnit_Framework_TestCase. Fortan ist es möglich mit seinen normalen Testklassen auch auf Exceptions zu testen.

Weiterhin ist es möglich nicht nur auf eine Exception allgemein zu testen sondern auf eine präzise Nachricht, die von der Ausnahme ausgegeben wird. Dieses Feature ist besonders da sinnvoll, wo viele Ausnahmetypen von einer Ausnahmeklasse abgeleitet werden, etwa bei Frameworks.

In Code bedeutet dies beispielsweise:

<?php
class Test extends PHPUnit_Framework_TestCase {
     public function testTest() {
           $this->setExpectedException('Exception', 'Ausnahme wurde geworfen');
           throw new Exception('Ausnahme wurde geworfen');
     }
}
?>

Es weihnachtet schon sehr und es ist die Zeit des Tuns guter Dinge. Warum nicht auch einmal diejenige Organisation unterstützen, deren Existenz man einen Großteil seiner Tools und Produktivität verdankt?

Die Eclipse Foundation hat nun eine Möglichkeit geschaffen, mit der auch Einzelpersonen, an die Foundation direkt spenden können. Alles was man braucht ist eine Kreditkarte oder einen Paypal-Account. Das Spendenprogramm wird hier vorgestellt, die Spendenseite ist hier zu finden.

Man kann sich aussuchen ob man mit seiner Spende anonym bleiben will oder in einer Liste veröffentlicht wird. Spender mit einer Summe ab $ 35 können zum “Friend of Eclipse” werden. Diese können ein spezielles Logo verwenden und sie bekommen Zugang zu einem dedizierten Mirror-Server für ihre Downloads.

In meiner losen Serie zu PHPUnit will ich heute auf eine einfache Möglichkeit hinweisen, zu überprüfen, welche Teile der getesteten Files wirklich von den Unittests abgedeckt sind und welche nicht.

PHPUnit bringt von Hause aus alles mit, um die Code Coverage durchzuführen. Das einzige was noch zur Analyse fehlt ist eine installierte und aktivierte PHP-Extension, nämlich XDebug. (Binaries von XDebug für die Mac OS X User finden sich hier, für den Fall dass man nicht selber kompilieren mag.) Danach (die Option –report steht nur bei installiertem XDebug zur Verfügung) langt es

phpunit --report /mein/zielverzeichnis MeinTest

an der Kommandozeile einzugeben und PHPUnit legt los. Der Report wird in das Verzeichnis geschrieben, welches als Parameter angegeben wurde. Die Abdeckungsanalyse arbeitet sowohl mit einzelnen Tests als auch mit kompletten Test-Suiten, so dass die Codeabdeckung kompletter Projekte auf einmal dokumentiert werden kann. Die Analyse geht bis auf Zeilenebene und erlaubt so sehr gut einen Einblick, wo noch potentielle Schlaglöcher in der Anwendung sein können.

Zend hat das auf den freien PHP Development Tools (PDT) aufbauende Zend Studio Neon als öffentliche Beta zum Download zur Verfügung gestellt. Zend wechselt damit von dem unsäglichen Swing als Unterbau für seine IDE hin zu Eclipse und dem SWT; alleine schon das ist ein Riesenfortschritt hinsichtlich Performance und Look & Feel der Anwendung.

Wir arbeiten schon lange (trotz aller Probleme und Fehler) mit den freien PDT und die Spannung ist natürlich groß, was für Features zusätzlich in das kommerzielle Paket Einzug halten.

Das Zend Studio gibt es momentan nur als Eclipse Distribution, also nicht als Plug-in, um es bereits existierenden Eclipse-Installationen hinzuzufügen, hoffentlich kommt das noch in späteren Versionen.

Die Beta arbeitet schon recht brauchbar, auch wenn die IDE an manchen Stellen noch einfriert oder sehr lange braucht (etwa Code Coverage bei den Unit Tests).

Die Featureliste von Zend Studio ist lang und sieht vielversprechend aus. Neben dem benannten Code Coverage von Unit Tests (die auch einen in die IDE integrierten grafischen Runner erfahren haben) gibt es einen sehr brauchbaren Echtzeit-Codeanalyzer. Annähernd wie man ihn von den Java Development Tools (JDT) kennt, nur nicht so ausführlich, er liefert aber dennoch gute Einblicke in den Code. Es gibt einen Profiler, der (mittels BIRT) auch grafische Ausgaben zum Profiling gibt, der auch in der Beta schon gut arbeitet. Und es gibt noch viele, viele andere Features, die das Zend Studio Neon von Eclipse PDT abheben. Das reicht von dem praktischen Generieren von Gettern und Settern bis hin zu der Fähigkeit, mittels der Zend Plattform auf dem Server zu Debuggen. Für andere Sachen wie ein Datenbankfrontend oder ein WYSIWYG-Editor für PHP / HTML greift Zend Studio in weiten Teilen auf andere Eclipse-Projekte zurück, ebenso wie für Subversion oder CVS. Natürlich steht es fem geneigten Entwickler frei, weitere Plugins seiner Wahl zu installieren, da gibt es ja für Eclipse fast alles.

Was mir persönlich momentan noch fehlt ist die Integration von Mylyn, der Task orientieren Oberflächenerweiterung für Eclipse. Gerade bei großen Projekten erleichtert Mylyn die Übersicht ungemein und es ist nur zu hoffen, dass die Integration bald folgt.

Insgesamt ein sehr vielverprechender Ansatz, der die spätere Anschaffung beim ernsthaften Entwickeln nahe legt. Zwar sind die Tools, die einem PHP-Programmierer zur Verfügung stehen noch meilenweit von denen eines Java-Entwicklers entfernt, aber Zend Studio ist meines Erachtens ein nützliches Tool im Rahmen seiner (Sprach-)Möglichkeiten.

Update: Beim intensiven Gebrauch der Software fiel mir ein Problem auf, und zwar auf Mac OS X und Windows gleichermaßen:
Wenn Zend Neon nicht ordnungsgemäß geschlossen wurde, verweigert die IDE unter bestimmten, noch unbekannten Bedingungen ihren weiteren Dienst. Sprich beim nächsten Start bleibt der Ladevorgang etwa in der Mitte hängen und die Anwendung reagiert nicht mehr. Abhilfe schaffte bislang nur das Löschen des kompletten “.metadata”-Verzeichnis aus dem zuletzt aktiven Workspace und das Neuanlegen der Projekte. Das Löschen der “.lock”-Datei alleine reichte nicht aus.

An sich erst für die Version 6 geplant aber vermutlich mit Version 5.3 beginnend erhält PHP Namespaces - zumindest wenn man diesem Blogeintrag folgt. Namespaces dienen dazu gleichnamige Identifier (Variablen, Methoden etc.) an bestimmte Namespaces zu binden und so die Probleme bei gleichnamigen Identifiern zu umgehen.

Mit der Einführung von Namespaces wird die Code-Organisation (bei großen Projekten) mit PHP vereinfacht. Auch umständliche Datei- oder Klassennamen wie

class Hauptkontext_Subkontext_Klassenname {

}

entfallen damit, da die Kontexte in Packages gepackt werden können und der Klassenname immer noch eindeutig ist.