Archer: Erfinder des Testing-Frameworks im Interview
Kommentare

Unlägst haben wir Euch Archer vorgestellt. Mit dem Toolset haben sich australische Entwickler ihren Test-Aufwand komplexer PHP-Anwendungen erheblich erleichtert. Nun sprachen wir mit ihnen über die Archers-Entstehung

Unlägst haben wir Euch Archer vorgestellt. Mit dem Toolset haben sich australische Entwickler ihren Test-Aufwand komplexer PHP-Anwendungen erheblich erleichtert. Nun sprachen wir mit ihnen über die Archers-Entstehung und darüber, wie sich das standardisierte Unit Testing im Feldeinsatz schlagen soll. Icecave-Chef James Harris beantwortete dazu einige Fragen. PHP Magazin: Wann kamt Ihr das erste Mal auf die Idee, PHP Unit Testing, API Docs und CI zu standardisieren? James Harris: Als wir Composer entdeckt haben, war es uns möglich, unser Management der Codebase auf der Arbeit komplett zu überdenken. Anstelle eines monolithischen Projekts konnten wir es in kleinere Komponenten aufsplitten. Das hatte einige Vorteile, erhöhte aber den Konfigurationsaufwand für jede einzelne Komponente. Am Ende hatten wir über 40 Komponenten; alle mit ihren jeweiligen Konfigurationen (je eine für reguläre Tests und eine für Abdeckungsberichte), sowie Bootstrap-Code für das Autoloading. Schnell wurde es fast unmöglich, jede Komponente auf dem aktuellen Stand zu erhalten. Also schrieben wir einen kleinen Wrapper um PHPUnit, der die Konfiguration für uns schrieb; was ziemlich gut funktionierte. Wenn wir dann unseren Testing-Prozess ändern wollten, mussten wir nur das Testing-Tool ändern, und nicht mehr jede einzelne Komponente.

Dieser Wrapper hat mittlerweile einige Iterationen hinter sich und ist schon recht stabil geworden. Nun wollte man das Projekt aber auch mal zuhause am eigenen Projekt verwenden. Und so enstand die Open Soure Variante, die später Archer heißen sollte.

PHP Magazin: Wie viele Leute, glaubt Ihr, werden Archer in ihrem derzeitigen Projekt verwenden können? Wie kompliziert wäre eine Umstellung auf Archer?

James Harris: Archer zu integrieren ist extrem einfach. In den meisten Projekten muss man oft nur ein oder zwei Verzeichnisse ändern und ein paar Config-Dateien löschen. Wenn Archer eine bestimmte Sache nicht unterstützt, ist es wahrscheinlich, dass es dasselbe Ziel auf eine bessere Weise erreicht.

Neulich zum Beispiel haben wir versucht, Monolog für Archer zu konfigurieren. Das ging auch ganz reinbungslos, bis wir auf eine Monolog-eigene Test-Case-Klasse stießen, die zwischen die anderen Test Cases in dasselbe Verzeichnis gespeichert wurde. Weil PHPUnit nur Test-Klassen via Autoloading lädt, befand sich zusätzliche Logik in einem eigenen Skript, um die eigene Test-Case-Klasse zu laden. Archer hingegen lädt gemäß PSR-0 alles, was im Verzeichnis test/src/ liegt, sobald die Tests ausgeführt werden. Also haben wir die Monolog-eigene Klasse einfach in das Verzeichnis geschoben. Somit haben wir nicht nur das Problem gelöst, sondern auch die eigentlichen Tests sauber vom restlichen Code separiert.

Neben den nützlichen Kommandozeilen-Tools, die wir hätten, würden wir weiter an unserem Fork von Monolog arbeiten, kann mann sofort die Vorteile erkennen in Form automatisch veröffentlichter Testabdeckungs-Berichte und der API Dokumentation, die in Monolog nicht verfügbar waren. Wer die vollständige Entwicklung nachvollziehen möchte, kann sich gerne das Commit Log im Repository ansehen.

PHP Magazin: Was ist, wenn ich Archer verwenden möchte, aber eine bestimmte Abhängigkeit von Archer in meinem Projekt nicht benutzen möchte?

James Harris: Archer ist auf die Voraussetzungen neuer Projekte abgestimmt und leider werden sich einige ältere Projekte nicht migrieren lassen. Eventuell sollte man wissen, warum jedes einzelne Requirement existiert, um eine informierte Entscheidung darüber zu treffen, ob man Archer verwenden kann.

Zunächst nutzt Archer PHPUnit. Wenngleich es nicht perfekt ist, ist es schon seit geraumer Zeit der de facto Standard für Unit Testing in PHP, und das wird sich so schnell auch nicht ändern. Wir haben es nicht als Composer-Abhängigkeit eingebunden, da es recht mächtig ist und seine Installation sehr lange braucht. Es ist also erste Voraussetzung, PHPUnit in seinem Pfad verfügbar zu haben.

Das Projekt benötigt Composer. Das stand für uns gar nicht zur Debatte. Wenn man jetzt noch nicht Composer verwendet, sollte man es absolut tun. Selbst wenn man ein komplett auf eigenen Füßen stehendes Projekt hat, und man nur seine Autoloading-Features verwendet, würde man noch immer davon profitieren. Archer nutzt die Konventionen, die Composer vorgibt. Wenn man also nicht zu Composer wechseln kann, kann man auch nicht Archer verwenden. Da gibt es keinen Ausweg.

Archer-Projekte müssen eine standardisierte Verzeichnisstruktur haben. Das ist weniger restriktiv als es zunächst klingt. In erster Linie bedeutet das, dass man seinen Code in src/ und alles Test-relevante in test/ speichert. Dieser Konvention folgen bereits sehr viele Projekte. Selbst wenn man diese Konvention noch nicht befolgt, sollte es trivial zu sein, dahin zu wechseln. Man muss nur sein Verzeichnis ändern und die Composer-Konfiguration anpassen. Dies ist eine Voraussetzung, um Testabdeckungs-Berichte und API-Dokumentation zu konfigurieren; neben weiteren Dingen.

Die letzte Voraussetzung sind Namespaces. Sie werden in alten Projekten nachträglich wohl am schwierigsten zu realisieren sein. Wir denken sogar darüber nach, diese Voraussetzung zu lockern und sie eher als Empfehlung zu sehen, da derzeit nur die API-Dokumentation wirklich davon abhängt. Wer darauf verzichten kann, der kann Archer wahrscheinlich auch ohne Namespaces nutzen. In neuen Projekten hingegen sollte man Namespaces verwenden und Vendor Präfixe nutzen, allein schon um die derzeitige Good Practice zu befolgen.

PHP Magazin: Von Euch stammt auch Woodhouse. Wird es auch eine Lana oder einen Cyril geben?

James Harris: Der Tradition folgend, unsere Testing- und Continuous-Integration-Tools nach Butlern zu benennen, haben wir uns für den Namen Woodhouse entschieden, als wir unser Werkzeug zum Hochladen von Build-Artefakten auf GitHub getauft haben. Es erschien uns passend, dass Archer noch immer Woodhouse für seine Drecksarbeit benutzt.

Jetzt, wo ich drüber nachdenke, müsste ein Projekt namens Lana ziemlich boshaft gegenüber Archer auftreten; vielelicht sollten wir die beiden lieber getrennt halten. 🙂

PHP Magazin: Möchtest du noch etwas Bestimmtes über Archer erzählen?

James Harris: So sehr Archer unsere Arbeit erleichtert, sind es die Software und die Dienste, auf denen Archer basiert – Composer, PHPUnit, Sami, Coveralls und Travis CI – die die eigentliche Arbeit machen. Es ist sehr ermutigend, dass die PHP-Gemeinde und die größere Open Source Community Testing und Continuous Integration als notwendigen Teil des Entwicklungsprozesses betrachten.

Wir pflegen einige PHP-Bibliotheken und andere Komponenten, stets mit einem starken Fokus auf Tests und Code-Qualität. Wer sich für unsere Arbeit interessiert, der sollte sich Icecave Studios (@jmalloc) und Eloquent Software (@ezzatron) ansehen.

PHP Magazin: Vielen Dank!

Aufmacherbild: Media interview von Shutterstock / Urheberrecht: wellphoto

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -