Die Selenium-RC Version 1.0.1 ist leider nicht kompatibel mit dem neuen Firefox 3.6.

Das Selenium Server Paket enthält einige Firefox Erweiterungen in denen eine maximale Kompatibilität zu Firefox 3.5 angegeben wurde. Diese Erweiterungen sind auch mit der Version 3.6 lauffähig, doch man muss die install.rdf Dateien anpassen.

Anleitung zum modifizieren des Selenium RC

1. Entpacke das Java Archiv selenium-server.jar
2. Suche alle Dateien mit dem Namen install.rdf in dem ausgepackten Verzeichnis.
3. Ändere in den Dateien den Wert <em:maxVersion>3.5.*</em:maxVersion> auf <em:maxVersion>3.6.*</em:maxVersion>
4. Erzeuge eine neue jar Datei
   1. Gehe in der Kommando Zeile in das ausgepackte Verzeichnis
   2. Stelle sicher dass das JDK im Pfad vorhanden ist.  (PATH=C:\Programme\Java\jdk1.6.0_18\bin)
   3. Erzeuge die neue Jar Datei: jar -cvfm selenium-server.jar META-INF/MANIFEST.MF *
5. Tausche die alte selenium-server.jar mit der neuen aus.

Die Coverage Analyse zeigt standardmäßig nur die Testabdeckung der Dateien an die innerhalb der Testausführung geladen wurden. Dadurch werden einige Dateien eventuell gar nicht beachtet und der Wert der Testabdeckung ist eigentlich zu hoch.

Wenn man phpunit mit einer Konfiguration XML Datei laufen lässt, kann man die Coverage Analyse mit dem Filter Tag anpassen.

Dem Tag whitelist kann man das Attribut addUncoveredFilesFromWhitelist verwenden. Dann werden auch die Dateien analysiert die gar nicht ausgeführt wurden.

...
<filter>
   <whitelist addUncoveredFilesFromWhitelist="true">
      <directory suffix=".php">../domain</directory>
      <directory suffix=".php">../system</directory>
      ...
</whitelist>
...

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.

Das Tool PHP_CodeSniffer ist ein praktisches Tool um den PHP Code auf Einhaltung der Coding Style Guides zu prüfen. Mann kann das Tool einfach über den Befehl phpcs aufrufen und auch relativ einfach eigene Sniffs erstellen die den Code prüfen.

Das Ergebnis kann in einer XML Datei ausgegeben werden und dann zum Beispiel in phpUnderControl eingebunden werden. Für die Entwicklung ist es aber recht mühsam die Stellen per Hand zu suchen und zu fixen. Besser geht das mit den den PHP Tools für Eclipse. Nach der Installation über die Update Seite hat man in den  Eclipse Einstellungen ein neuen Bereich mit den Einstellungen für den CodeSniffer.

Hier lässt sich einfach ein eigener “Coding Standard” auswählen.

Danach steht das Programm im Kontext Menü zur Verfügung. Man kann den CodeSniffer auch in den Validierungs Prozess von Eclipse aktiveren.

Dann werden die Dateien automatisch mit den CodeSniffer validiert.

Die Fehler oder Warnungen werden in der Datei angezeigt:

Unter Windows gibt es noch einen kleinen Bug mit den DIRECTORY_SEPARATOR der sich umgehen lässt indem man eine eigene PEAR Libary einbindet und dort den Bug behebt. Ich suche aber noch nach einer eleganteren Lösung.

Ganz praktisch dafür ist ist die Möglichkeit der Debug Ausgabe in der Eclipse Console.

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.