Ich beschäftige mich jetzt seit einiger Zeit mal mehr mal weniger intensiv mit Themen wie Testing, Code Qualität, Continuous Integration, etc. Das Ziel, welches ich aber eigentlich verfolge ist folgendes:

Ich bin PHP Entwickler und arbeite gerne und intensiv mit dem symfony Framework. Ich bin also vor allem daran interessiert meine symfony Anwendungen zu testen. Hier jetzt das Dilemma.

symfony kommt mit seinem eigenen (durchaus xUnit konformen) Testingwerkzeug lime.

Lime is more lighweight than PHPUnit or simpletest and has several advantages. First, it launches test files in a sandbox to avoid strange effects between each test file run (one of the reasons we were unable to fix the old symfony core tests). It also introduces a new sfBrowser, sfTestBrowser and more importantly sfDomCssSelectorBrowser that allow you to write functional tests with ease. It is not backward compatible but is a lot more powerful than the old system. Oh, and it holds in a single file, lime.php, without any dependence. [symfony blog]

Wo ist jetzt das Dilemma? Nun lime ist eben nicht PHPUnit, was seinerseits als de facto Standard angesehen werden kann und wunderbar in Tools wie phpUnderControl und xdebug integrierbar ist. Man findet dazu einfach eine Menge Informationen im Netz. Lime wiederum wird meines Wissens ausserhalb von symfony nicht verwendet, stattdessen wird es in der symfony Entwicklung in ein eigenes CI System sismo integriert, welches aktuell closed source ist.

Ich (und sicher eine Menge anderer symfony Entwickler) wollen aber ein eigenes CI System betreiben in welches sich alle selbstgeschriebenen Tests leicht integrieren lassen. Ich liebäugle dafür mit phpUnderControl / CruiseControl, beides open source und gut genug dokumentiert.

Dass ich nicht der einzige bin, der sich mit diesem Thema beschäftigt sehe ich an immer wiederkehrenden Diskussionen zum Thema in den symfony Google Groups symfony-users oder symfony-devs. Ausserdem gibt es das symfony Plugin sfPHPUnitPlugin, welches eine PHPUnit Integration in symfony verspricht und dann noch das symfonyUnderControlPlugin, welches die lime Tests in phpUnderControl integrierbar machen will.

Einige Entwickler hatten sich auch Hoffnungen gemacht, dass mit dem dieses Jahr erscheinenden Symfony 2.0 auch das Testing auf PHPUnit umgestellt werden wuerde. Diesen Hoffnungen hat Fabien Potencier (creator of symfony) allerdings eine Absage erteilt, weil die Migrationsschritte wohl zu gross geworden wären.

Stattdessen hat sich Bernhard Schussek darangemacht lime als Lime 2 weiterzuentwickeln. Zwei interessante Blogposts über seine Beweggründe hat er hier und hier geschrieben. Wie man dann mit Lime 2 testet hat er bereits auf dem symfony Day Cologne 2009 vorgestellt.

Ich persönlich bin hin- und hergerissen zwischen den beiden Technologien.

Zum einen würde ich gerne PHPUnit verwenden, da es sich einfach um einen mittlerweile gut verbreiteten Standard handelt, der sich wiederum am xUnit Standard orientiert. PHPUnit ist gut dokumentiert und weiter gibt es jede Menge Blogposts, die sich mit der Installation auf den unterschiedlichsten Systemen, der Integration mit anderen Technologien wie Xdebug und phpUnderControl oder auch einfach nur mit dem Umgang mit PHPUnit beschäftigen. Es gibt sogar Bücher, in denen PHPUnit betrachtet wird. Die Entwicklung von PHPUnit wiederum liegt bei Sebastian Bergmann, der sein Projekt sehr aktiv und engagiert vorantreibt. PHPUnit ist ausserdem eine Technologie, die man sehr wiedertreffen wird, wenn man z.B. in einem neuen Job Test Driven Development mit PHP praktizieren soll (kann, darf, ..), man lernt also was für sich selbst unabhängig von einem Framework o.ä. .

Zum anderen finde ich die enge Verbindung von lime und symfony sehr sexy. Wenn man viel mit dem Framework arbeitet sind zwei Komponenten ständige Begleiter: die symfony Tasks und die symfony Dokumentation und lime ist in beide vollständig integriert. Es gibt Tasks, die die Functional Tests und / oder die Unit Tests ausführen und die Tasks zum Generieren von z.B. Modulen legen auch immer gleich entsprechende Tests an (die natürlich noch mit Leben gefüllt werden müssen), was sehr praktisch ist. Und auch in der Dokumentation spielt lime immer wieder eine Rolle. So wird immer wieder darauf eingegangen, wie wichtig es ist immer wieder neue Tests zu schreiben und diese auch auszuführen aber halt auch, wie diese geschreiben werden. Und es ist schon super, wenn man nicht in einer weitere Dokumentation und Technologie springen muss, wann immer man testen will (zumindest anfangs wird das wohl der Fall sein).

Will man nun allerdings nicht nur Tests schreiben und manuell ausführen, sondern sie kontinuierlich als Integrationstests laufen lassen und sie z.B. in phpUnderControl einbinden hat man ein Problem. Nämlich jenes, dass die vielen PHP Blogger da draussen, sich viel zu selten aber ausreichend mit dem Thema Continuous Integration zusammen mit PHPUnit beschäftigen, aber noch viel weniger mit dem Thema CI im Zusammenspiel mit symfony / lime. Es besteht also die Notwendigkeit, sich intensiver mit phpUnderControl und der Einbindung von Tools zu beschäftigen.

Zwar bietet lime (und natürlich auch Lime 2) die Möglichkeit xUnit konformes XML für Test Runs und Coverage zu erstellen, aber diese wird in der Dokumentation bisher nur selten und unzureichend beschrieben z.B. in diversen Blogpost Kommentaren oder in Google Group Diskussionen.

Bisher konnte ich zwei Ansätze einzelner symfony Nutzer finden symfony und phpUnderControl zu verbinden.

Der erste Ansatz ist das sfPHPUnitPlugin, das versucht PHPUnit in symfony zu integrieren. Es stellt Tasks bereit, die Tests anlegen und generiert eine AllTests.php, die von phpUnderControl aufgerufen werden kann. Ausserdem bietet es Wrapperklassen, die die prozeduralen Functional Tests von symfony kapseln und ebenfalls von PHPUnit und somit phpUnderControl ausführbar machen. Der Nachteil dieses Ansatzes ist meiner Meinung nach, dass somit Teile der symfony Dokumentation unbrauchbar werden und stattdessen die PHPUnit Dokumentation zu Rate gezogen werden muss. Mein Bauchgefühl ist aber auch, dass die Verbindung der symfony mit den PHPUnit Schnittstellen soviel Arbeit bedeutet, dass es wahrscheinlich ist, dass nicht alle Features beider Technologien verfügbar sein dürften. Und die Dokumentation der Integration also des Plugins wird somit umfangreicher und eine dritte Quelle, die man u.U. zu Rate ziehen muss. Man muss aber erwähnen, dass die Arbeiten an dem Plugin recht aktiv zu sein scheinen.

Der zweite Ansatz kommt unter anderem von Stefan Koopmanschap und seinem symfonyUnderControlPlugin. Die Idee hier ist es lime das Format beizubringen, welches von phpUnderControl verstanden wird, also xUnit konformes XML. So ziemlich denselben Ansatz verfolgte auch das sfTest4CruisePlugin, welches ebenfalls xUnit konformes XML erzeugt. Mit diesem Ansatz verliert die symfony Dokumentation keinerlei Bedeutung. Allerdings ist das sfTest4CruisePlugin komplett verweist und symfonyUnderControl nicht so ganz einfach zum Laufen zu bekommen, da die Dokumentation scheinbar nicht ganz vollständig ist. Ausserdem ist es seit bereits einiger Zeit nicht mehr weitergewickelt worden. Ich habe Stefan mal angeschrieben und er sagte es wäre definitiv nicht tot aber sicher in einem momentanen Tiefschlaf. Auch das kann open source sein.

Aber wie ich bereits erwähnte ist lime (laut Fabien Potencier seit symfony 1.3) durchaus in der Lage xUnit konformes XML zu generieren. Wozu also ein extra Plugin? Auch das habe ich Stefan gefragt und auch er war sich nicht sicher, in wie weit das bereits ausreichend ist.

Moment mal!

Ich suche hier schon nach einer möglichen Intrgation von Lime und phpUnderControl. Scheinbar habe ich mich also schon gegen PHPUnit entschieden? Naja, sagen wir ich habe eine gewisse Präferenz entwickelt während ich diesen Blogpost geschrieben und recherchiert habe, eine abschliessende Entscheidung ist es jedoch nicht, denn die hängt sicher auch davon ab, wie sich diese Integration gestaltet. Aber bevor ich damit weitermache will ich kurz darlegen, wie sich meine Präferenz zusammensetzt.

Es ist weder so, dass ich PHPUnit ausschliesse noch, dass ich lime bevorzuge. Ich bin vielmehr der Meinung, dass beide Technologien ihren Anwendungsbereich haben.

In einer Arbeitsumgebung, in der man mit unterschiedlichen Technologien zu tun hat, die alle zentral getestet werden müssen, wäre es beispielsweise absurd sich gegen PHPUnit zu entscheiden. So ist z.B. die Situation bei meinem Arbeitgeber, wo ich mich vermutlich eher für PHPUnit entscheiden würde. Auch wenn lime unabhängig von symfony verwendbar ist, ist es jedoch nicht separat dokumentiert und warum sollte man es sich antun immer wieder die lime Teile aus der symfony Dokumentation rauszusuchen, wenn man es gerade z.B. mit einem WordPress Plugin zu tun hat? In solchen Umgebungen, in denen symfony eben nur einen Teil der eingesetzten – und damit zu testenden – Technologien darstellt, macht es viel mehr Sinn in den symfony Projekten mit nicht integrierten PHPUnit Tests zu arbeiten, als nicht-symfony Projekte mit lime zu testen, was dort keinerlei Vorteile bietet. Es ist ungemein wichtig in solchen Situationen einen einzelnen und immer gleichen Testansatz zu verfolgen, um zu gewährleisten, dass alle Entwickler überall testen können. Unnötige Technologiewechsel während der Arbeit erhöhen nur die Komplexität und verringern im schlimmsten Fall sogar die Akzeptanz der Entwickler.

Es gibt aber auch Fälle, wo man vielleicht ausschliesslich mit symfony Projekten zu tun hat oder wo das Testing einzelner Projekte vollständig voneinander getrennt stattfindet beispielsweise direkt beim Kunden. Das ist bei meinen privaten Projekten der Fall und dort reduziert es eher die Komplexität mit der ich umzugehen habe, wenn ich mich ausschliesslich im symfony Kontext bewegen kann. Auch könnte ich mir vorstellen, wenn ich mit anderen symfony Entwicklern zusammenarbeite, dass diese eher mit lime als mit PHPUnit Erfahrungen haben.

Unterm Strich sind also beide Technologien berechtigt. Aber ich schreibe dieses Blog nicht für meinen Arbeitgeber, sondern für mich und werde mich deshalb auf meine eigenen Anforderungen konzentrieren. Auf der Arbeit werden meine so gewonnenen Erfahrungen sicherlich irgendwie mit einfliessen, aber dort hängt die Entscheidung für die ein oder andere Technologie sinnvollerweise nicht nur von mir ab.

Also mein vorläufiges Ergebnis: Ich werde versuchen lime mit phpUnderControl zu integrieren, möglichst ohne den Einsatz von weiteren Plugins. Meine Ergebnisse – erforlgreich oder auch nicht – werde ich weiterhin hier schildern.

Folgende Links sollen mir dabei helfen:

• http://anoosphpundercontrol.wordpress.com/2008/07/29/phpundercontrol-framework-for-symfony-projects/
• http://www.leftontheweb.com/message/symfonyUnderControl_lime_integration_with_phpUnderControl
• http://blog.naenius.com/2009/08/using-symfonys-lime-in-phpundercontrol/
• http://blog.bascht.com/continuous-integration-mit-symfony

Hoffentlich kommt eine gute Anleitung dabei heraus, die auch anderen hilft ihre symfony Tests zu automatisieren.

ps: Cool übrigens, wie einem so ein Blogpost bei der Selbstfindung helfen kann.

Bernhard Schussek, Continuous Integration, Fabien Potencier, lime, phpUnderControl, phpUnit, Stefan Koopmanschap, symfony, xUnit