Zunächst zwei Klassen, eine davon definieren wir als abstract class:

<?php
    class AnotherRealObject {
    
        public function __call($method, $args) {
            return 'AnotherRealObject->'.$method.'()'; 
        }
    
    }

    abstract class SomeAbstractClassWithConcreteMethods {

        private $anotherObject;
    
        abstract public function abstractMethod();
    
       public function concreteMethodToSetObject($o) {
            $this->anotherObject = $o;
        }

        public function concreteMethod() {
            return $this->anotherObject->aMethod();
        }
    
    }        
?>   

Soweit nichts aufregendes. AnotherRealObject enthält lediglich eine Methode, die bei einem beliebigen Methoden-Aufruf einen String zurückgibt, der angibt welche Methode auf dem Objekt aufgerufen wurde. Mal kurz in einer interaktiven PHP-Shell getestet sieht das ganze so aus:

    php > $stub = new AnotherRealObject();
    php > echo $stub->blubb();
    AnotherRealObject->blubb()
    php > echo $stub->someMethodWithAnArbitraryName();
    AnotherRealObject->someMethodWithAnArbitraryName()  

Die zweite Klasse ist abstract definiert. Das hat für diesen Beitrag keinen besonderen Grund, ich wollte in meinen Tests einfach nur ausschließen, dass das Problem darauf zurückzuführen ist. Die Klasse hat zwei konkrete Methoden. Eine zum Setzen der Abhängigkeit $anotherObject und eine weitere, die auf diesem Objekt eine Methode aufruft und deren Rückgabewert zurückgibt.

Ein phpUnit Test um die abstrakte Klasse zu testen könnte wie folgt aussehen:

    class phpUnitBugTest extends PHPUnit_Framework_TestCase {

        private $uut;
        private $stub;

        public function setUp() {

            $this->uut = $this->getMockForAbstractClass('SomeAbstractClassWithConcreteMethods');

            $this->stub = $this->getMock('AnotherRealObject');
            $this->stub->expects( $this->any() )
                          ->method('aMethod')
                       ->will ( $this->returnValue('StubOfAnotherRealObject->aMethod()') );

            $this->uut->concreteMethodToSetObject($this->stub);
        }


        public function testBug() {
            $this->assertEquals('StubOfAnotherRealObject->aMethod()', $this->uut->concreteMethod());
        }


    }

Mit der durch phpUnit bereitgestellten Methode getMockForAbstractClass() instanzieren wir eine Instanz der abstrakten Klasse (das Testobjekt). Außerdem instanzieren wir ein Stub von AnotherRealObject und legen fest, dass beim Aufruf der Methode aMethod auf diesem Stub der String StubOfAnotherRealObject->aMethod() zurückgegeben wird. Anschließend wird das Stub noch in die Instanz der abstrakten Klasse injected.

Soweit so gut – fehlt der eigentliche Test. Was sollte passieren, wenn auf dem TestObjekt die Methode concreteMethod() aufgerufen wird? Nun ja, die Methode ruft auf dem Feld $anotherObject die Methode aMethod auf. Dem Feld $anotherObject ist unser Stub zugewiesen und dem Stub haben wir gesagt, dass es beim Aufruf von anotherMethod den String StubOfAnotherRealObject->aMethod() zurückgeben soll. Dementsprechend sollte ein aufruf von concreteMethod() genau diesen String zurückliefern.

Leider spielt phpUnit hier nicht mit. Der Test schlägt fehl:

    There was 1 failure:

    1) phpUnitBugTest::testBug
    Failed asserting that two strings are equal.
    --- Expected
    +++ Actual
    @@ @@
    -StubOfAnotherRealObject->aMethod()
    +

    dev/phpUnitBugTest.php:45   

Wie man sieht gibt es gar keinen Rückgabewert. Aber warum ist das so? PhpUnit erstellt nur Method-Stubs für Methoden, die es tatsächlich in der Klasse gibt. Die Methode aMethod gibt es aber nicht wirklich, also erstellt phpUnit auch kein Stub dafür. Es gibt allerdings eine einfache Lösung für das Problem – auch wenn ich sie nicht besonders schön finde: Man sagt phpUnit einfach explizit, dass es einen Stub für die Methode aMethod erstellen soll. Dies geschieht beim erzeugen des Stubs:

    $this->stub = $this->getMock('AnotherRealObject', array('aMethod'));

Mit dieser Änderung läuft der Test durch. Aber Vorsicht: PhpUnit erstellt jetzt nur Stubs, die durch den Parameter festgelegt wurden. D.h. es müssen alle Methoden in diesem Array übergeben werden, für die Subs angelegt werden sollen – egal ob diese in der eigentlichen Klassen existieren oder nicht. Und genau dies ist auch der Grund, warum ich diese Lösung nicht schön finde.

Wenn man mit Mockito ein Objekt mockt, stellt das Framework automatisch stubs für equals() und hashCode() bereit. Deshalb läuft folgender JUnit Test ohne Fehler durch:

@Test
public void testMockito() {

    BigDecimal o1 = mock(BigDecimal.class);
    BigDecimal o2 = mock(BigDecimal.class);

    assertEquals(false, o1.equals(o2));
}

Da Mockito sich also um equals() und hashCode() kümmert kann man ge’mockte Objekte auch einfach mit einer Map benutzen. Dazu zum Beispiel folgender Test:

@Test
public void testMockitoWithHashMap() {

    BigDecimal o1 = mock(BigDecimal.class);
    BigDecimal o2 = mock(BigDecimal.class);

    Map<BigDecimal, String> map = new HashMap<BigDecimal, String>();
    map.put(o1, "erster Mock");

    assertEquals(true, map.containsKey(o1));
    assertEquals(false, map.containsKey(o2));   
}

Läuft. Super. Aber Vorsicht. Der gleiche Test mit einer TreeMap schlägt fehl:

@Test
public void testMockitoWithTreeMap() {

    BigDecimal o1 = mock(BigDecimal.class);
    BigDecimal o2 = mock(BigDecimal.class);

    Map<BigDecimal, String> map = new TreeMap<BigDecimal, String>();
    map.put(o1, "erster Mock");

    assertEquals(true, map.containsKey(o1));
    assertEquals(false, map.containsKey(o2));   
}

So sieht die Fehlermeldung dazu aus:

java.lang.AssertionError: expected:<false> but was:<true>
    [...]
    at [...].testMockitoWithTreeMap(Test.java:92)
    [...]

Erfahrene Java Entwickler wissen natürlich sofort was hier los ist. Für alle anderen dürfte es nach einem Blick in die API von TreeMap klar werden:

Note that the ordering maintained by a sorted map (whether or not an explicit comparator is provided) must be consistent with equals if this sorted map is to correctly implement the Map interface. (See Comparable or Comparator for a precise definition of consistent with equals.) This is so because the Map interface is defined in terms of the equals operation, but a map performs all key comparisons using its compareTo (or compare) method, so two keys that are deemed equal by this method are, from the standpoint of the sorted map, equal. The behavior of a sorted map is well-defined even if its ordering is inconsistent with equals; it just fails to obey the general contract of the Map interface.

Was bedeutet dies für das Mocking mit Mockito? Beim Aufruf von map.containsKey(o2) im letzten Test oben, wird intern irgendwann o2.compareTo(o1) aufgerufen. Im Interface java.lang.Comparable ist die Methode wie folgt definiert:

int compareTo(T o)

Compares this object with the specified object for order. Returns a negative integer, zero, or a positive integer as this object is less than, equal to, or greater than the specified object.

Da Mockito versucht sinnvolle Rückgabewerte zu erzeugen, wird der Aufruf von o2.compareTo(o1) “0″ zurückgeben. 0 bedeutet aber in diesem Fall das o1 und o2 gleich sind. Deshalb liefert der Aufruf von map.containsKey(o2) auch ein true.

Ein kleiner Test dazu:

@Test
public void testMockitoWithTreeMapAndVerifyCompareToCall() {

    BigDecimal o1 = mock(BigDecimal.class);
    BigDecimal o2 = mock(BigDecimal.class);

    Map<BigDecimal, String> map = new TreeMap<BigDecimal, String>();
    map.put(o1, "erster Mock");

    assertEquals(true, map.containsKey(o1));

    verify(o2, times(0)).compareTo(o1);
    map.containsKey(o2);
    verify(o2, times(1)).compareTo(o1);
}

Mit diesem Wissen können wir den Test von weiter oben umschreiben, so dass auch dieser durchläuft:

@Test
public void testMockitoWithTreeMap() {

    BigDecimal o1 = mock(BigDecimal.class);
    BigDecimal o2 = mock(BigDecimal.class);

    when(o2.compareTo(o1)).thenReturn(1); // NEU

    Map<BigDecimal, String> map = new TreeMap<BigDecimal, String>();
    map.put(o1, "erster Mock");

    assertEquals(true, map.containsKey(o1));
    assertEquals(false, map.containsKey(o2));   
} 

Mit nur einer neuen Zeile läuft der Test von vorhin nun korrekt durch. Der Aufruf von o2.compareTo(o1) liefert nun 1, was bedeutet das o2 “größer” ist als o1 und somit nach o1 in der TreeMap eingeordnet wird.

Fazit

Für erfahrene Java Entwickler ist dieser Post mit Sicherheit nichts Neues und so wie ich das Problem hier beschrieben habe, ist der Fehler auch sofort ersichtlich. Wenn man allerdings eine Klasse testet die intern eine TreeMap benutzt, nach außen aber nur das Map Interface sichtbar macht, ist ein solcher Fehler nicht gleich ersichtlich und vielleicht verwirrend.

Neben der Erkenntnis über die Implementierungs-Unterschiede zwischen HashMap und TreeMap hat mir dieses Problem heute mal wieder gezeigt, wie wichtig und sinnvoll Testing ist. Durch das Schreiben dieses einen Tests habe ich ein neues Detail der Java API kennengelernt, mich näher mit Mocktio beschäftigt und gleich zwei Probleme in meinen eigenen Klassen gefunden und beseitigen können. So muss das sein!

Zunächst erstmal alle Tools herunterladen, installieren und konfigurieren. Ich habe mir die SpringSource Tool Suite heruntergeladen. Da ist alles dabei, sowohl Spring Roo, als auch Maven und ein Spring Source Server zum lokalen Testen der Anwendungen. Nach dem Entpacken habe ich alles nach ~/Applications/ kopiert (Achtung, das ist kein Standard-Ordner unter OSX – den habe ich mir für lokale Anwendungen angelegt). Damit man Roo und Maven einfacher benutzen kann, muss das ganze noch in den Pfad aufgenommen werden. Dazu linke ich die Skripte einfach nach /usr/bin:

    sudo ln -s /Users/dennis/Applications/roo-1.1.0/bin/roo.sh /usr/bin/roo
    sudo ln -s /Users/dennis/Applications/maven-2.2.1.RELEASE/bin/mvn /usr/bin/mvn

Achtung, die Pfade könnten bei dir etwas anders sein! Nicht einfach copy/pasten.

Im Anschluss habe ich erstmal die SpringSource Tool Suite (STS) gestartet und im Willkommens-Bildschirm über “Install Extension” den Support für GWT installiert. Danach möchte STS einmal neu gestartet werden und dann kanns auch schon losgehen. Natürlich kann man jetzt einfach die IDE benutzen und das erste Spring Roo Projekt erstellen, aber ich wollte die Roo Konsole testen – über die IDE kann das ja jeder

Also wieder zurück auf die Konsole, ein neues Verzeichnis im Workspace anlegen und die roo-Shell aufrufen:

    cd ~/springroo
    mkdir testApp
    cd testApp
    roo

In der roo-Shell habe ich folgende Befehle ausgeführt:

    project --topLevelPackage io.dennis.roo.amawish
    persistence setup --provider HIBERNATE --database HYPERSONIC_IN_MEMORY 
    entity --class ~.domain.Item
    field string --fieldName label
    entity --class ~.domain.Account
    field string --fieldName email
    field set --fieldName items --element ~.domain.Item
    gwt setup
    perform eclipse
    perform clean

Die Befehle kannst du auch als roo-Script herunterladen und ausführen. Das Skript einfach in das testApp Verzeichnis kopieren und dann in der roo-Shell folgenden Befehl ausführen:

    script --file setup.roo

Wenn das Skript durchgelaufen ist (kann einen Moment dauern) kann man das Projekt am schnellsten über Maven starten. Dazu die roo-Shell verlassen (Command: quit) und Maven seine Arbeit machen lassen:

    mvn gwt:run

Jetzt kann man das Projekt im Browser aufrufen. Bei mir sieht das ganze so aus:

Das ging schnell oder? Wenn man jetzt an dem Projekt weiterarbeiten möchte kann man es ganz einfach in STS importieren (“File” > “Import” > “Existing Projects into Workspace”).

Nach einer kurzen Google Recherche musste ich feststellen, dass im Netz auch kein brauchbarer PHP Getter/Setter Generator aufzutreiben ist. Also, nicht lange rumdümpeln, schreibe ich mir halt schnell selbst einen – sowieso die Gelegenheit sich mal die PHP Reflection API anzuschauen. Hier das Ergebnis nach 10 Minuten Arbeit:

#!/usr/bin/php
<?php

    if (!is_file($argv[2])) 
        die('Use this way: '.$argv[0].' <class_name> <path_to_your_class`s_php_file>'."\n");

    require_once($argv[2]);

    $class = new $argv[1]();
    $reflection = new ReflectionClass($argv[1]);
    $fields = $reflection->getProperties(
        ReflectionProperty::IS_PRIVATE
        | ReflectionProperty::IS_PROTECTED
    );

    foreach ($fields AS $f) {

        // getter
        echo 'public function get'.ucfirst($f->getName()).'() {'."\n";
        echo "\t".'return $this->'.$f->getName().';'."\n";
        echo '}'."\n";
        // setter
        echo 'public function set'.ucfirst($f->getName()).'($val) {'."\n";
        echo "\t".'$this->'.$f->getName().' = $val;'."\n";
        echo '}'."\n\n";

    }
    echo 'Generated Getter and Setter for '.count($fields).' fields'."\n\n";
?>   

Das ganze ist ein PHP-Konsolenscript. Als Parameter den Namen eurer Klasse und den Pfad zur PHP Datei mitgeben in der die Klasse deklariert ist. Als Ausgabe erhält man die Getter- und Setter-Methoden für alle Felder, die als private oder protected deklariert sind. Vielleicht hat ja noch jemand anders Verwendung dafür – mir hats eine Menge Zeit gespart

Zum Glück muss man bei WordPress mit solchen Schönheitsfehlern nicht leben – ein kleines MiniPlugin genügt um seine eigene Email-Adresse und den Absendernamen festzulegen. Hier erstmal der Code:

<?php
/*
Plugin Name: myemail
Plugin URI: http://blog.kips-world.de
Description: Some wordpress hacks for my website
Version: 1.0
Author: Dennis Saenger
Author URI: http://blog.kips-world.de
*/

function kip_from_mail($f) {

        $admin = get_userdata(1);
        return $admin->user_email;
}
function kip_from_name($f) {

        $admin = get_userdata(1);
        return $admin->display_name;
}
add_filter('wp_mail_from', 'kip_from_mail', 0, 1);
add_filter('wp_mail_from_name', 'kip_from_name', 0, 1);
?>

Um den Absendernamen und die Emailadresse zu ändern benutze ich hier je einen WordPress-Filter. Immer wenn WordPress eine Email verschicken will, werden diese beiden Filter automatisch aufgerufen. Als Parameter übergibt WordPress die Default-Werte an die Funktionen. Bei kip_from_mail() übergibt WordPress “wordpress -ät- blog.kips-world.de”, bei kip_from_name() wird “WordPress” übergeben. Man könnte diese Werte jetzt modifizieren und zurückgeben, aber ich habe mich dafür entschieden einfach den Nickname und die Emailadresse des Admin als Absender zu nutzen. Ich ignoriere die Variablen ($f) in beiden Funktionen also einfach und hole mir mit der Funktion get_userdata() einfach die Werte des admin Users (der admin hat die User-ID 1).

Um das ganze selbst auszuprobieren erstellst du in deinem WordPress-Pluginordner einfach eine Datei “myemail.php” und kopierst den obigen PHP-Code dort hinein. Im Admin-Bereich von WordPress wird es dann ein neues Plugin “myemail” geben. Dieses noch schnell aktivieren und schon sendet WordPress Emails mit einem schönen Absender!

Wer jetzt Lust bekommen hat selbst kleine Modifikationen an WordPress vorzunehmen findet im WordPress-Codex alles was er wissen muss. In der Plugin-API gibt es eine Einführung zu Filtern und Actions (die beiden Plugin-Schnittstellen von WordPress). In der Function Reference werden alle WordPress-Funktionen inklusive Beschreibung aufgelistet. Und auf der Homepage von Adam findet man eine komplette Liste mit allen Filtern und Actions (sehr wichtig!).

Unter MacOSX gibt es dafür natürlich einige grafische Tools, nicht zuletzt den Automator. Dieser bennent auf Wunsch beliebig viele Dateien um, allerdings mit festem Namen und einer laufenden Nummer. Ich wollte die Namen meiner Bilder allerdings behalten und nur den störenden Teilstring entfernen.

Hier zeigt sich mal wieder warum ich meinen Mac so mag: Geniales GUI – aber unter der Haube ein Unix mit all seinen nützlichen Tools! Einen Teilstring aus allen Dateinamen eines Ordners zu entfernen ist für ein Unix und die Bash keine Herausforderung – dazu braucht man nur eine einzige Befehlszeile:

for FILE in * ; do NEWFILE=echo $FILE | sed -E 's/bearb_#?//g' ; mv "$FILE" "$NEWFILE" ; done

Die Befehle im Detail:

• for FILE in *; do: Eine For-Schleife die nacheinander alle Dateien im aktuellen Verzeichnis einliest und deren Dateinamen in der Variable $FILE spiechert.
• NEWFILE=` … `: Diese Anweisung führt eine neue Variable $NEWFILE ein und weist ihr die Ausgabe der Befehle zwischen den Anführungszeichen zu. Die schrägen Anführungszeichen haben die Besonderheit, dass der String zwischen ihnen als Unix-Befehl ausgeführt wird.
• echo $FILE | sed -E ‘s/bearb_#?//g’: echo $FILE gibt einfach nur den alten Dateinamen aus und die Pipe (der senkrechte Strich: | ) leitet die Ausgabe von echo auf den zweiten Befehl sed um. sed kann mit Hilfe von Regulären Ausdrücken Zeichenketten bearbeiten. Der Parameter -E aktiviert die erweiterten Regulären Ausdrücke von sed. Das s vor dem ersten Schrägstrich weist sed an, den String zwischen den ersten beiden Schrägstrichen mit dem String zwischen dem 2. und 3. Schrägstrich zu ersetzen. Der 2. String ist leer, was bedeutet, dass der mit dem 1. Regulären Ausdruck gefundene String einfach gelöscht wird. Der Reguläre Ausdruck ist einfach der Teilstring den ich entfernen muss. Das #-Zeichen kam in manchen Strings nicht vor. Damit der Reguläre Ausdruck Teilstrings in der Form “bearb_” und “bearb_#” findet, steht das ?-Zeichen hinter dem #-Zeichen. Ein ?-Zeichen bedeutet bei Regulären Ausdrücken, dass ein Zeichen genau 0- oder 1mal vorkommen darf.
• done: Das abschließende done beendet die for-Schleife.

Problem gelöst – mit Unix Hausmitteln, ohne extra Tools!

Planet ist ein serverseitiger Feedreader für Aggregator-Dienste, der zur Zusammenfassung verschiedener Nachrichtenquellen auf Websites genutzt wird. [...] Im übertragenen Sinn wird der Begriff allgemein für Websites verwendet, die mittels eines Feed-Aggregators verschiedene Nachrichtenquellen, vor allem Blogs, zusammenfassen.

Der erste Schritt muss nun sein das ich mir ein Design überlege. Es soll etwas sehr einfaches sein, was aber andererseits auch an Apple erinnern darf. Ich denke ich werde mich an Me.com orientieren. In die graue Leiste oben muss ein schönes Logo (ein Planet der nach einem Apfel aussieht wäre genial oder? ).

Dannach muss ich mich auf die Suche nach ein paar Seiten machen die sich am Planet beteiligen möchten. Ich möchte keine Apple-News Seiten aufnehmen, es sollen rein private Blogs sein. In meinem Newsreader haben sich in letzter Zeit einige “Apple”-Blogs angesammelt. Wenn die Seite steht und der Feedreader auf dem Webserver läuft werde ich die Webmaster mal anschreiben.

Ich denke ich werde als Reader “das Original” einsetzen. Dafür brauche ich zwar Python auf dem Webserver, aber wenn man seinen eigenen Root-Server hat, ist das weniger ein Problem. Dann kann ich das nächste mal gleich über die Installation und Konfiguration des Planet bloggen …

Wer sich mal ein paar Beispiele anschauen möchte kann ich den planet.ubuntuusers.de, planet.gnome.org oder den planet-index empfehlen.

Ich arbeite schon seit längerem mit Aptana. Die Standard Version von Aptana Studio ist kostenlos und bringt alle wichtigen Funktionen die ich benötige mit sich. Das schöne an Aptana, es basiert auf Eclipse und ist als Standalone Anwendung aber auch als Eclipse Plugin zu haben. Da ich Eclipse sowieso auf dem Rechner habe, benutze ich die Plugin-Version von Aptana.

Die Plugin-Version von Aptana wird wie jede andere Erweiterung für Eclipse installiert. In der Eclipse IDE auf “Hilfe” > “Neue Software installieren” und die Aptana Update Seite hinzufügen. In den folgenden Dialogen sicherstellen, dass die Kästchen für Aptana Studio aktiviert sind – fertig.

Wenn Aptana Studio installiert ist und Eclipse neu gestartet wurde, wird man mit einem neuen Fenster begrüßt. In diesem Fenster können weitere Aptana Plugins installiert werden. Ich habe hier Aptana PHP, jQuery Support und Subversive nachinstalliert. Der Aptana CSS und HTML Editor ist im Studio schon integriert.

Wenn alles fertig installiert ist sollte man noch ein paar Einstellungen machen. Unter den Eclipse Einstellungen findet man nun einen neuen Unterpunkt “Aptana”. In “Aptana” unter “Editoren” > “PHP” > “PHP Bibliotheken” kann man zunächst Smarty aktivieren und dann zusätzlich eigene Bibliotheken hinzufügen. Ich habe hier mein PHP Framework pew hinzugefügt. Die hier aktivierten Bibliotheken liest Apatana ein und bietet eine Autovervollständigung für die Befehle der Bibliotheken an. Für PHP, HTML und CSS macht Aptana das selbstverständlich schon standardmäßig.

So, jetzt kann es endlich losgehen. Über “Datei” > “Neu” > “Aptana Projekte” > “PHP Projekt” kann nun ein neues Aptana PHP Projekt gestartet werden! Demnächst werde ich dann noch beschreiben wie man das SVN Plugin Subversive richtig installiert und konfiguriert.

Wem der Funktionsumfang von Eclipse + Aptana immernoch nicht genug ist, der kann sich einmal auf eclipseplugincentral.com umschauen. Dort finden sich noch über 1000 andere Plugins für Eclipse! Wer was gutes findet darf mir gerne Bescheid sagen