In unserem aktuellen Projekt werden ziemlich viele Selenium Tests erstellt und ausgeführt. Selenium Tests bedürfen einer besonders Intensiven Wartung und Pflege. Der Künde wünschte sich ein Monitoring über den Zustand der Tests in zeitlicher Hinsicht. Jenkins bietet einige Plugins zur Visualisierung an, aber das reichte uns nicht. Ziel war es eine Gesamtsicht  und Einzelsicht auf alle Test Module zu haben. Bei jeden Test sollte erkennbar sein bei welchen Build Lauf er erfolgreich war oder nicht.

UnitTH ist ein kleines Java Tool das aus den Unit Test Ergebnis Dateien einen Report erzeugen kann.

Das Tool untersucht bestehende Unit Test Report XML Dateien und erzeugt daraus ein einen Report. Die zeitliche Achse wird durch Build Läufe erzeugt. UnitTH erkennt die Build Läufe anhand von Ordnern.

Die Reports muss in dieser Struktur vorliegen:

/build1/junit_log1.xml
/build1/junit_log2.xml
/build2/junit_log1.xml
/build2/junit_log2.xml

In den Ordnern können beliebig viele XML Dateien liegen.

Testsuiten sind für das Tool sogenannte Module. Damit wird der Report gegliedert. Man muss also darauf achten das die Suiten in den Reports eindeutige Namen haben und nicht verschachtelte Suiten haben. Meine Report Dateien haben nicht ganz dem Schema entsprochen. Ich wandel die Dateien mit XSLT um.

Der Aufruf erfolgt so:

java -jar -Dunitth.report.dir=/…/unitth/report unitth.jar /…/unitth/xml/*

Man gibt also nur das Ziel Verzeichnis für die Reports und den Pfad zu den XML Dateien.

In den Report bekommt man eine praktische Übersicht über den aktuellen Stand der Tests und den Trend.

Über die Graphen kann man erkennen, wie sich die Testdauer verhält und ob sich die Anzahl der Tests verändert.

Man bekommt eine Liste der Build Läufe und darin zusammengefasst wie deren Status war. Hier sieht man auch schön die aktuellen Trends.

Die Module (Testsuiten) werden auch zusammengefasst dargestellt und man kann sich auf einer Unterseite den Verlauf auf Testcase Basis anschauen. Dadurch kann man besonders kritische Testfälle erkennen und dann stabilisieren.

Das spannendste Feature ist die Spread Ansicht. Hier sieht man, bei welchen Build die Testfälle fehlgeschlagen sind. Damit kann man sogenannte “Blinker” Test finden. Um diese dann zu Isolieren.

Hier ein kurzer Rückblick auf die Typo3 Konferenz in Hanau und die PHP Konferenz in Mainz.

Typo3 Konferenz

Die Konferenz fand dieses Mal in Hanau statt und hatte angenehmere Räume als die letzten Jahre. Das Catering hat sich aber leider extrem verschlechtert und war ungenießbar.

Sonar

Es gab einen Vortrag über Sonar,  ein Tool mit dem man sehr übersichtlich Metriken darstellen kann. Es war für mich neu, dass es unter http://metrics.typo3.org/ einen Sonar Server mit den Metriken zu allen Typo3 Extension gibt.

Ein Mitarbeiter der d.k.d  plant eine neue TER Plattform in der man diese Sonar Daten mit einer Suche verknüpfen kann und darüberhinaus die Extension noch mit Sozialen Daten anreichern kann. Eine schöne Vision die eventuell Ende des Jahres verfügbar ist.

Flow3

Das Flow3 Framework steht vor der ersten stabilen Version. In einem Talk wurden die Erfahrungen mit Flow3 in der Praxis präsentiert. Als Fazit kann man sagen das Flow3 schon einsatzfähig ist und sich der Einsatz lohnt. Wenn man schon mit Extbase gearbeitet hat, ist der Einstieg extrem leicht. Das kann ich nur bestätigen, da wir Flow3 auch in der Praxis einsetzen und keinerlei Probleme hatten.

IPC11

Die PHP Konferenz fand wieder mal in Mainz statt und hier war das Catering richtig gut.

PHP 5.4

Traits

Die schönste Neuerung in PHP 5.4 sind für mich die Traits. Damit kann man quasi eine Mehrfachvererbung einsetzen. Ich hatte immer mal wieder Stellen bei denen das notwendig gewesen wäre.

Class Produkt {
    Public function getPreis(){}
}
Class UserItem {
    Public function getItemId(){}
}
Class UserProdukt extends UserItem use Produkt(){
}

In diesen Fall habe ich ein Produkt aus einen Katalog und ein gekauftes Produkt eines Kunden. Mit Hilfe der Traits kann ich bei meinen Kunden Objekten in meiner Vererbungslinie bleiben, aber trotzdem die Produkt Methoden verwenden. Man kann das Vererbungsverhalten auch noch konfigurieren und die Namen der Methoden überschreiben oder deren Sichtbarkeit ändern.

Arrays in Rückgaben verwenden

Es ist jetzt möglich Arrays aus Rückgabewerten direkt zu verwenden ohne die Variable zwischen zu speichern:

foo()[42]

Neuer Typehint

Leider gibt es immer noch keine Typehints für scalare Werte. Dafür gibt es einen neuen Typehint callable.

Integrierter Webserver

PHP hat jetzt einen integrierten Webserver für Development Zwecke. Dieser ist sehr einfach gestrickt und mir ist der Sinn dessen nicht ganz klar geworden.

JsonSerializable

Über das neue Interface JsonSerializable kann man steuern welche Daten beim json_encode indem man die Daten über die Methode jsonSerialize zurück gibt.

Openstreetmap

Es gab einen spannenden Vortrag über Geo Berechnungen mit vielen Formeln einiges an Theorie zu diesen Thema. Es wurde besonders das Projekt Openstreetmap hervorgehoben. Dieses bietet eine gute Alternative zu Google Maps, da man die Daten lokal speichern kann und somit auch mit Karten ohne Internet Verbindung arbeiten kann.

Slides

Liquibase

Über Liquibase wurde ja vor kurzem im PHP Magazin berichtet. Hier hatte ein Entwickler von Mayflower seine Erfahrungen mit Liquibase geteilt. Mit Liquibase kann man die Datenbank Änderungen versionieren und sehr komfortabel deployen. Es ist ein sehr mächtiges Java Tool das sich gut in Continuus Deployment Prozesse integrieren lässt.  Besonders interessant, finde ich die Roleback Möglichkeit. Auch andere Teilnehmer in den Talk berichteten von ihren Positiven Erfahrungen mit dem Tool.

Unter dieser Adresse findet man alle Links zu den Slides der Konferenz
http://joind.in/event/view/806

Die CopyPaste Detection für PHP (phpcpd) ist eine wunderbare Sache und lässt sich einfach aufrufen und in phpUnderControl integrieren. Doch die Stellen zu suchen und zu Eliminieren kann schon etwas mühsam sein. Deutlich einfacher geht es mit dem Eclipse Plugin:  PHP Tool Integration. Hier kann man seit kurzem nicht nur den CodeSniffer innerhalb von Eclipse nutzen, sondern auch die CopyPaste Detection.

Das Tool lässt sich einfach über das Context Menü aufrufen:

Im Editor werden dann die Fehler angezeigt:

Zur Installation sollte man diese Eclipse Update Seite verwenden:

http://www.phpsrc.org/eclipse/pti/

Danach muss man noch die Einstellungen anpassen und die PHP Executable und die PEAR Libary anpassen:

Ich nutze die Eclipse PHP Tool Integration Tools jetzt standardmäßig wegen der guten  Code Sniffer Integration wie bereits in einen älteren Blogbeitrag beschrieben.

Darüber hinaus beinhaltet das Eclipse Plugin auch eine Funktion zum schnellen Ausführen von Unit Tests.

Wenn man an einen Unit Test arbeitet kann man einfach einen Button im Eclipse anklicken zum Ausführen des Tests.

Erstmal ist das relativ unspannend, da das selbe passiert wie bei einem Kommandozeilen Aufruf und die Ausgabe nur  unschön in der Eclipse Console erscheint.

Es spart aber immerhin einen Toolwechsel und einige Klicks.

Wirklich praktisch finde ich aber die Auswertung der Fehler im Editor von Eclipse. Dort wird die Stelle wo der Fehler aufgetreten ist als unterstrichener Fehler markiert.

Es wird nicht nur die Stelle im Test markiert sondern Fehler die in den getesteten Code Aufgetreten sind. Wenn dort ein PHP Fehler auftritt oder eine Exception geworfen wird die nicht abgefangen wird, wird diese Stelle markiert. So braucht man nicht anhand der Zeilen Nummern die Stellen suchen.

Bei der Erstellung der Codecoverage mit phpUnit bin ich schon mehrmals aus diesen PHP Fehler gestoßen:

PHP Fatal error:  Cannot redeclare class

Aus dem Code war kein Grund dafür ersichtlich da alle Dateien mit require_once eingebunden waren. Das Problem lag dabei in der Verwendung von Mock Klassen ohne diese vorher importiert zu haben.

Ich kann mit folgenden Code eine Object der Klasse Example erstellen ohne die original Klasse zu laden.

$object = $this->getMock ( 'Example', array (), array (), '', false );

Wenn danach die original Klasse Example importiert wird, ist diese schon deklariert und es kommt zu diesen Fehler. Abhilfe tut hier ein require_once im Test:

require_once('path/to/Example.php');
$object = $this->getMock ( 'Example', array (), array (), '', false );

Dann klappt es auch mit der Coverage Auswertung.

Leider gibt es in den PHP Tools für Eclipse einen kleinen Bug unter Windows wenn man ein eigenen Coding Standard verwenden will. Der PHP_CodeSniffer kann mit dem Parameter –standard aufgerufen werden und der CodeSniffer sucht in dem Pfad nach Sniff Dateien. Der CodeSniffer verwendet dafür die PHP Konstante DIRECTORY_SEPARATOR die ja bekanntlich unter Windows ein \ ist und kein /. Jetzt sollte man unter Windows den CodeSniffer wie folgt aufrufen:

phpcs --standard=C:\path\to\standard

Wenn man aber bei den PHP-Tools in die Debug Ausgabe schaut wird folgender Befehl ausgeführt

phpcs --standard=C:/path/to/standard

Dadurch findet der CodeSniffer die Dateien nicht.

Ich habe den Bug gemeldet und hoffe das es bald behoben ist.

Als Workaround habe ich den CodeSniffer innerhalb des PEAR Packet angepasst und folgende Zeile ergänzt:

PHP\CodeSniffer.php Zeile 400

$this->standardDir = str_replace('/',DIRECTORY_SEPARATOR,$this->standardDir);

In Eclipse muss man dann noch bei den PHP-Tools Einstellungen die lokale PEAR Libary verwenden.

Sebastian Bergmann hat mit phploc ein kleines Tool geschaffen, das einem ein kurzen Überblick über die Beschaffenheit des PHP Projektes gibt. Im Gegensatz zu PHP_Depend beschränkt sich die Auswertung auf ein paar werte, die aber für eine Auswertung innerhalb eines continues integration Prozess ausreichen würde. Es eignet sich nicht um die Schwachstellen zu finden.

Sinnvoll ist es auch zu zur Prüfung ob ein Opensource Projekt den eigenen Ansprüchen genügt oder ob ein schlechter Code zu erwarten ist mit dem man auf Dauer nicht arbeiten kann.

phploc wird einfach über den PEAR Installer installiert und kann dann über die Komandozeile über diesen Befehl aufgerufen werden.

> phploc "C:\...."

Ich habe ein bekanntes Projektmanagementtool mit diesen Tool getestet und folgendes Ergebnis bekommen.

Auffällig ist das hier keinerlei Interfaces und Abstrakte Klassen verwendet werden. Der Code ist relativ gut dokumentiert. Die Methoden haben mit durchschnittlich 36 Zeilen zu viel Logik und auch die Cyclomatische Komplexität ist etwas zu hoch. Der hohe Anteil an öffentlichen Methoden sprechen für eine potentielle Instabilität. Dafür scheint die Package Struktur übersichtlich zu sein.