Viele Fehler treten bei Magento schon durch eine fehlerhafte Konfiguration auf, was zur Folge haben kann, dass wir keine Instanz unser lokalisierten Klasse bekommen, sondern ein standard Magento-Objekt oder einen Fehler, weil keine passende Klasse gefunden wird.

So habe ich also angefangen, die Existenz der zu prüfenden Klassen zu testen und ob die Mage-Factory das gewünschte Objekt zurück gibt. Bei einigen Klassen ist es zudem auch noch wichtig, dass sie von der richtigen Elternklasse abgeleitet sind.

Da sich diese Tests immer wiederholten, zeichnete sich schnell ein Muster ab. Ebenso erfolgt auch die Namesgebung der Magentoklassen nach einem gewissen Muster. Was wäre also naheliegender, als beides miteinander zu verbinden und so in Zukunft eine Menge unnützer Schreibarbeit zu sparen?

Als erstes habe ich dafür einen erweiteren TestCase vom PHPUnit-TestCase abgeleitet, der mir weitere vereinfachte Asserts zur Verfügung stellt und die Tests dadurch auch etwas lesbarer macht.

$this->assertClassExists($classname);

statt

$this->assertTrue(class_exists($classname));

Auf diesem Wege lassen sich dann auch z.B. Getter und Setter einfach auf das gewünschte Standardverhalten prüfen.

Im nächsten Schritt habe ich einen Entity-TestCase abgeleitet, der als Basis für alle weiteren TestCases für Models, Blocks und Helper dienen soll. Dieser ist in sich schon ein wenig intelligenter und erkennt anhand des Namens der Test-Klasse, welche Klasse getestet werden soll, welchen Typ diese hat und welche die Standard-Elternklasse ist.

Diese Informationen werden, nebenbei bemerkt, durch protected Methoden ermittelt und könnten zu jeder Zeit durch noch speziellere TestCases wieder überschrieben werden.

Mit den nun vorliegenden Informationen ist diese TestCase-Klasse mächtig genug, um alleine durch Vererbung die grundlegenden Tests durchzuführen.

Für die jeweiligen Typen, z.B. Model habe ich dann noch weitere TestCases abgeleitet, um dort noch spezielle Methoden implementieren zu können.

Ein sehr einfacher Test für die Model-Klasse “Mein_Customer_Model_Customer” sähe dann beispielsweise so aus:

class Mein_Customer_Model_CustomerTest extends Mein_Model_TestCase
{
}

Dadurch würde nun automatisch getestet werden, ob der Autoloader die Klasse “Mein_Customer_Model_Customer” finden kann, diese von der Magento-Model-Klasse erbt und ob die Factory aufgrund der Konfiguration auch das richtige Objekt liefert.

Ich denke, dass es viel einfacher nicht mehr geht und das Argument gegen Tests damit dann auch aus der Welt sein sollte.

Kleiner Tipp: Wenn man es nun noch etwas konfortabler mag, dann kann man sich seine Models auch mit dem Zend_CodeGenerator bauen lassen und die Tests gleich mit.

Die meisten PHP-Programmierer, sofern sie nicht auf einem Linux-System mit grafischer Oberfläche arbeiten, werden das Problem sicherlich gut kennen.

Wenn man nur einen Rechner zur Verfügung hat und alle Dienste unter Windows laufen entspricht das sicherlich nicht unserem Live-System und wir können nicht alles zuverlässig testen und sind auch sonst an vielen Stellen eingeschränkt in unserer Arbeit. Zudem laufen die Dienste in der Regel immer mit an, auch wenn wir nicht Programmieren wollen und verbrauchen dann unnötig Rechenleistung.

Die zweite Möglichkeit wäre dann noch ein zweiter Entwicklungsrechner, auf dem wir ein Linux installieren und dann über das Netzwerk arbeiten. Das würde uns einen weiteren Rechner und natürlich auch noch Strom kosten. Selbst wenn dieser Entwicklungsserver von einem ganzen Team genutzt würde, besteht immernoch die Gefahr, das eine Mitarbeiter die Kiste aus Versehen in die Knie zwingt.

Durch die Arbeit mit der Virtuellen Box (oder vergleichbaren Programmen) kann nun jeder Entwickler auf seinem Windows gleichzeitig auch ein Linux-System zur Verfügung haben und dessen Vorteile nutzen (z.B. SymLinks, Cronjobs).

Einmal installierte und konfigurierte Systeme lassen sich exportieren und wieder an andere Verteilen, so dass eine einheitliche und dennoch individuelle Entwicklung möglich ist. Die Zeitersparnis beim Aufsetzen eines neues Entwicklungsrechners ist dabei enorm.

Die Gastsysteme können nach der Installation gewöhnlich wie jeder andere Rechner im Netzwerk angesprochen werden, d.h. wir könnten unsere PHP-Dateien mit FTP hochladen oder einfach eine Samba-Freigabe unseres virtuellen Servers nutzen.

Auf die einzelnen Schritte der Installation gehe ich in diesem Artikel nicht ein, könnte das aber bei ausreichenden Interesse für einen weiteren Artikel einplanen.

Meine Installation basiert auf einem Debian-Linux. Die Konfiguration beinhaltet neben den typischen LAMP-Komponenten (Apache2, MySQL und PHP5), u.A. Samba für die Netzwerkfreigabe, einen SSH-Server, um mit PuTTY darauf arbeiten zu können, PEAR, PHP-CodeSniffer, PHPUnit, Apache Ant, sowie phpMyAdmin und verschiedene Zend Framework Versionen.

Das exportierte Image ist dabei mit 734 MB klein genug, dass es auf einer CD oder einem USB-Stick weitergeben werden kann.

Die Technik der Virtualisierung ist nicht neu, aber ich denke, es ist eine gute und vor allem kostengünstige Alternative zu den anderen genannten Möglichkeiten.