Sie sind auf Seite 1von 11

www.techdivision.

com

PHPUnit Tests mit Magento


Ist der Einsatz der Magento 2 Testsuite in Magento mglich? Und wie luft die Portierung?
Index: Mgliche Testverfahren Portierung der Testsuite Anlegen von Testdaten Probleme beim Einsatz der Testsuite Fazit

TechDivision GmbH

PHPUnit Tests mit Magento

Eine der grten Schwchen von Magento, wenn man im Vergleich zu anderen Shopsystemen berhaupt von Schwchen sprechen kann, besteht sicherlich im Fehlen einer PHPUnit-Testsuite analog der, die mit Magento 2 eingefhrt wird. Da seitens Magento momentan kein naler Fertigstellungstermin fr Magento 2 genannt wurde, wird Magento sicherlich noch lnger als ursprnglich erwartet fr Projekte zum Einsatz kommen. Anscheinend wird dem auch seitens Magento Rechnung getragen, da sich seit Version CE 1.7.x sowie EE 1.12.x auch hinsichtlich der Testbarkeit mit PHPUnit einiges getan hat. Jeder Entwickler, der mit Magento arbeitet, vermisst sicherlich schmerzlich eine Testsuite, die die Basisfunktionalitt von Magento mit Unit- und Integrationsstest automatisiert testbar macht. Zustzlich sollen natrlich auch die eigenen Entwicklungen fr sich

sowie in Abhngigkeit der Basisfunktionalitt testbar sein. Sieht man sich die Testsuite von Magento 2 etwas detaillierter an, ist gut erkennbar, in welche Richtung Magento hier knftig gehen wird. Nachdem die Qualitt fr die Solution Partner als eines der zentralen Kriterien in die Bewertung des Partners mit einiet, stellt Magento seinen Entwicklungspartnern knftig mit der Testsuite und dem Magento Automated Testing Guide [1] die Tools fr die notwendige Verbesserung der Qualitt, und somit auch der Partnerbewertung durch Magento, zur Verfgung. Dieser Artikel beschreibt die notwendigen Schritte zur Migration der Testsuite von Magento 2 auf Magento und zeigt anhand von Beispielen diverse Einsatzmglichkeiten sowie die mgliche Integration in einen Build- und Deploymentprozess.
von Tim Wagner

Magento stellt seinen Entwicklungspartnern knftig die Testsuite und den Magento Automated Testing Guide [1] zur Verfgung. Mgliche Testverfahren
Die Testsuite bringt Tests fr die gngigsten vier Testverfahren mit. So werden Unit-, Integrations- und Performancetests ausgeliefert. Zustzlich enthlt die Suite Tests fr die statische Code-Analyse. Bis auf die Performance Tests bauen alle Tests auf PHPUnit [2] von Sebastian Bergmann auf. Dieser Artikel beschftigt sich hauptschlich mit den Unit- und den Integrationstests, da diese fr die meisten Entwickler die grte Bedeutung haben. Durch die Integration dieser beiden Testverfahren wird die Qualitt und somit die auch Wartbarkeit von Magento-Projekten mittel- und langfristig erheblich steigen. Auf die statische Code-Analyse mchte ich in diesem Artikel nicht nher eingehen, da diese im Rahmen des Build- und Deploymentprozesses separat abgehandelt werden kann, und sie zum anderen zum Migrationszeitpunkt nur sehr rudimentr seitens Magento implementiert war. Auch auf die Performancetests wird nicht nher eingegangen, da diese ber JMeter umgesetzt und ebenfalls separat aufgerufen werden mssen.

TechDivision GmbH

PHPUnit Tests mit Magento

Portierung der Testsuite


Aufbauend auf unserem Build- und Deploymentprozess, bei dem der Entwickler die Mglichkeit hat, ber das eingesetzte Buildtool, in unserem Fall ANT [3], jederzeit automatisiert eine neue Magento-Instanz zu erstellen, war, neben einer sprbaren Steigerung der Qualitt, eines der Primrziele der Portierung, dass beim Erstellen einer neuen Entwicklungsinstanz dem Entwickler die Tests umgehend zur Verfgung stehen und diese somit nahtlos in alle Entwicklungsprozesse integriert sind. Die Portierung erfolgte in drei Schritten und begann im April 2012. Schritt 1: Testsuite als Extension bereitstellen Im ersten Schritt wurden die zum Portierungszeitpunkt aktuellen Sourcen von Magento 2 aus dem GIT Repository geclont. Anschlieend wurde die Testsuite im Rahmen einer eigenen Extension so aufgesetzt, dass sie zum einen in jedem Magento-Shop ab Version CE 1.7.x/EE 1.12.x installiert, und zum anderen ber einen automatisierten Prozess fr jede zuknftige Magento-Version ein um die Testsuite erweitertes Installationspaket erstellt und auf einem Buildserver bereitgestellt werden kann. Die Extension enthlt somit, wie in Illustration 1 dargestellt, neben der notwendigen Konguration und den HelperKlassen im app-Verzeichnis den Bootstrapper (1), die Verzeichnisse dev (2), das aus den Magento-2-Sourcen bernommen wurde, sowie die Verzeichnisse lib + downloader (5 + 3). Das lib-Verzeichnis enthlt einige fr Magento 2 spezische Klassen, die die Testsuite jedoch fr die Initialisierung bentigt. Im downloader-Verzeichnis benden sich die von frheren Magento-1-Versionen bentigten Dateien fr den Downloader. Dieser wird zwar mit aktuellen MagentoVersionen nicht mehr ausgeliefert, jedoch fr das erfolgreiche Erstellen des Code-Coverage-Reports bentigt. Magento referenziert hier in einigen Dateien immer noch flschlicherweise PEAR-Klassen (4), die fr den Betrieb eigentlich nicht mehr bentigt werden. Bei der statischen Code-Analyse mit PHPUnit tritt jedoch ein Fatal Error auf, falls diese Klassen nicht im downloader-Verzeichnis gefunden werden knnen. Optional knnte auch ber die Whitelist in der phpunit.xml.dist auf die Prfung der entsprechenden Sourcen durch PHPUnit beim Erstellen des CodeCoverage Reports verzichtet werden. Schritt 2: Anpassen der Testsuite an Magento Im zweiten Schritt musste die mit Magento 2 ausgelieferte Testsuite an Magento angepasst werden. Zu Beginn der Migration hatten wir Magento CE 1.6.x/EE 1.11.x als Zielversion vorgegeben. Es stellte sich jedoch relativ schnell heraus, dass hierbei fr den Einsatz des Testframeworks Anpassungen an den Magento-Core-Klassen notwendig wren. Ab Version CE 1.7.x/EE 1.12.x wurden die notwendigen Anpassungen bereits von Magento direkt im Core vorgenommen, was Anpassungen fr den Einsatz der Testsuite berssig macht.

Illustration 1: Verzeichnisstruktur Testsuite

TechDivision GmbH

PHPUnit Tests mit Magento

berarbeitung der Tests Zu den notwendigen Anpassungen zhlten die berarbeitung des Bootstrappings, auf das wir spter noch nher eingehen werden, sowie Anpassungen der eigentlichen Tests, wobei Letzteres aufgrund von Einschrnken in Magento zu den wesentlich aufwndigeren Arbeiten gehrte. Aufgrund von Anpassungen der Architektur, hauptschlich hinsichtlich Design und Layout, konnten viele Tests aus Magento 2 nicht 1:1 bernommen werden, da entweder Verzeichnisse und Dateien schlichtweg nicht vorhanden waren, Methoden sich gendert hatten, oder gnzlich neu hinzugekommen waren. Eine unschne Einschrnkung von Magento hat sich bereits beim berarbeiten der Tests gezeigt. So knnen die Annotations zum Anlegen von Testdaten (siehe ) in Magento 2 entweder auf Klassen- oder Methodenebene angegeben werden. Beim Einsatz mit Magento traten hierbei jedoch in vielen Fllen Probleme hinsichtlich inkonsistenter Testdaten auf, die wohl auf Anpassungen in Magento 2 im Bereich der Datenbankschicht hindeuten. Die betroffenen Testflle musste bei der Migration entsprechend berarbeitet, also die entsprechenden Annotationen auf Methodenebene gesetzt oder gar deaktiviert werden. Betroffene Testflle, aktuell ca. 630, wurden nicht gelscht, sondern vielmehr geskippt und werden nach und nach geprft und berarbeitet. Weiterhin wurden zum Zeitpunkt der Portierung 27 Testflle durch Magento als incomplete deklariert. Auch diese werden, falls sinnvoll, in knftigen Versionen der Testsuite fertiggestellt.

Anpassen des Bootstrappings Fr das Ausfhren der Unit- und der Integrationstest wird die Testsuite ber einen Bootstrapper initialisiert. Der Bootstrapper wird, wie in Listing 1 dargestellt, in der PHPUnit-Kongurationsdatei phpunit.xml.dist registriert, er initialisiert die Laufzeitumgebung zum Ausfhren der Testsuite.
01 <phpunit bootstrap="./framework/bootstrap.php"> ... 50 </phpunit> Listing 1: Konfiguration PHPUnit Bootstrapper

Im Fall der Unittests werden hier lediglich die Includepfade gesetzt, der Autoloader initialisiert und das Verzeichnis zur Speicherung von temporren Dateien geleert. Fr die Integrationstests ist hier wesentlich mehr Aufwand notwendig, da eine Magento-Sandbox auf Basis der aktuellen Shopkonguration, sowie eine Testdatenbank erstellt werden muss. Auerdem erweitert Magento PHPUnit um zustzliche Prolingmglichkeiten und einige Observer, die das Schreiben von Tests fr den Entwickler erheblich vereinfachen. So stehen ber die durch die Testsuite zustzliche bereitgestellten Annotations @magentoAppIsolation @magentoDataFixture @magentoCongFixture dem Entwickler Funktionen zum automatisierten Anlegen von Test- und Kongurationsdaten sowie zur Ausfhrung eines einzelnen Tests in einer isolierten (zurckgesetzten) Instanz zur Verfgung.

TechDivision GmbH

PHPUnit Tests mit Magento

Testen in der Sandbox


Die Testsuite erzeugt vor dem Ausfhren der Tests eine Sandbox. Hierzu werden alle globalen sowie die in den Extensions enthaltenen Kongurationsdateien in ein temporres Sandbox-Verzeichnis unterhalb der jeweiligen Testsuite kopiert. Auf Basis der dort erstellten Verzeichnisstruktur wird der Shop whrend des Bootstrappings initialisiert. Da fr die Tests Anpassungen an den Kongurationsdateien notwendig sind, stellt dieses Verfahren sicher, dass fr die Ausfhrung der Tests keinerlei Vernderungen am Shop vorgenommen und diese vollkommen isoliert und ohne Nebeneffekte vom Livesystem ausgefhrt werden. Local- vs. Distributiontesting Whrend der Einfhrungsphase hat sich gezeigt, dass es aus Zeitgrnden in der Praxis nicht mglich ist, bei jedem lokalen Build alle Tests laufen zu lassen. Auf einem gut ausgestatteten Entwicklungsrechner dauert der Durchlauf der gesamten Testsuite einschlielich des Code Coverage Reports bereits ber 15 Minuten. Hinzu kommen noch die Tests der jeweilige Extension. Fr die lokale Entwicklung und fr die Erstellung einer neuen Paketversion steht neben der Standard-Kongurationsdatei phpunit.xml.dist, die alle Tests ausfhrt (Distributiontesting), noch eine Kongurationsdatei phpunit.xml.local zur Verfgung, die nur die Tests im Namespace der aktuellen Extension ausfhrt (Localtesting). Heit die Extension z. B. TechDivision_GermanTax, so werden beim Aufruf der Tests unter Verwendung der Kongurationsdatei phpunit.xml.local alle Tests unterhalb des Verzeichnisses dev/tests/integration/testsuite/ TechDivision durchlaufen und der Code Coverage Report ausschlielich fr alle Dateien der jeweiligen Extension erstellt, was, abhngig von der Anzahl der Tests, zu einer erheblichen Zeiteinsparung fhrt. Schritt 3: Integration in den Entwicklungsprozess Mit die grte Herausforderung der Portierung war der dritte und somit letzte Schritt: Die Integration in den Entwicklungsprozess. Mit Magento 2 werden die Testsuite und die Tests standardmig ausgeliefert. Die Sourcen von Magento hingegen kommen natrlich ohne Testsuite. Um eine mglichst nahtlose und einfache Integration zu gewhrleisten, wurden zur lokalen Entwicklung eingesetzte Magento-Pakete um die Testsuite erweitert. So knnen die Tests zum einen ber ein ANT-Target jederzeit aus der lokalen Entwicklungsumgebung heraus gestartet werden, zum anderen kann beim Build noch vor dem Erstellen des Pakets sichergestellt werden, dass das Paket erst dann erstellt wird, wenn alle Tests fehlerfrei durchlaufen wurden. Hierbei kann der Entwickler durch Aufruf der verschiedenen ANT-Targets zu jedem Zeitpunkt entscheiden, welche Testflle, also Unit- und/oder Integrationstests, ausgefhrt werden sollen. Zustzlich besteht die Mglichkeit, ber Build Properties zu denieren, ob nur die jeweiligen Tests der aktuell zu entwickelnden Extension oder zustzlich auch die Core Tests ausgefhrt werden sollen. Fr den Build- und Deployment Prozess knnen Tools wie Phing oder, wie in unserem Fall, ANT verwendet werden. Zum Ausfhren der Test stehen die in Listing 2 aufgefhrten Targets zur Verfgung.
01 phpunit-run-all-tests 02 phpunit-run-unit-tests 03 phpunit-run-integration-tests Listing 2: ANT Targets zur Ausfhrung der Unit Tests

Das ANT-Target phpunit-run-integration-tests startet, wie der Name schon sagt, die Integrationtests der Testsuite. In der aktuellen Version werden derzeit 1.950 Tests ausgefhrt, wobei davon, wie bereits zuvor beschreiben, wegen Inkompatibilitten mit Magento noch 628 geskippt werden und 27 incomplete sind. Die aktuelle Testsuite mit 2.990 Assertions deckt ca. 11 % der Magento-CoreKlassen ab, sprich noch knapp 90 % des MagentoQuelltexts sind nicht durch Tests abgedeckt. Diese Targets knnen entweder direkt aus der lokalen Entwicklungsumgebung oder automatisch whrend des Builds durch den CI Server ausgefhrt werden. ber die Build Properties (siehe Listing 3) kann konguriert werden, ob und welche (Distribution oder Local) Tests whrend des Builds ausgefhrt werden sollen. Zustzlich kann konguriert werden, welche Datenbank fr die Ausfhrung der Integrationstest verwendet werden soll, standardmig wird eine zustzliche leere Datenbank erzeugt.

TechDivision GmbH

PHPUnit Tests mit Magento

01 phpunit.tests.execute = false 02 phpunit.database = ${mysql.database}_tests 03 phpunit.testsuite = dist Listing 3: Build Properties zur Konfiguration der ANT-Targets

Illustration 2 zeigt die Ausgabe der Kommandozeile nach dem Durchlauf der Integrationstests der aktuellen Version der Testsuite.

Illustration 2: Integrationstests auf Kommandozeile starten

Laufen die Tests ohne Fehler durch, wird das Paket erstellt und automatisch im PEAR Channel hinterlegt. Selbstverstndlich muss nicht zwingend PEAR fr das Paketmanagement verwendet werden, PEAR hat sich allerdings in den letzten Jahren in unserem Fall bewhrt. Aktuell wird ein Ersatz durch Composer geprft. Um sicherzustellen, dass jede Extension fr sich selbst, sowie im Zusammenspiel mit allen anderen Extensions im Rahmen eines Projekts lauffhig ist, wird pro Extension und zustzlich pro Projekt ein eigener Job im CI Server angelegt. Wird eine nderung durch den Entwickler in das GIT Repository der Extension gepusht, wird automatisch durch den CI Server der Build gestartet, die extensionspezische Testsuite ausgefhrt und nach erfolgreichem Durchlauf ein neues PEAR Paket mit der aktuellsten Version gebaut und
TechDivision GmbH PHPUnit Tests mit Magento

auf dem Channel Server zur Verfgung gestellt. Vor dem Release eines Projekts werden alle Extensions in der aktuellsten Version installiert und alle Tests Core und Extension ausgefhrt. Erst, wenn alle Tests ber ein Projekt erfolgreich durchlaufen, wird das neue Release zum Deployment freigegeben. ber das Jenkins Frontend (Illustration 3) haben Scrum Master und Product Owner bereits whrend des Sprints die Mglichkeit, die verschiedene Metriken, sowie die Anzahl der erstellten Unit- und Integrationstests im Auge zu behalten. Nach Abschluss des Sprints gewhrleisten die Tests, dass auch bei der Weiterentwicklung der Extension oder des Shops die Qualitt einfach und effektiv sichergestellt werden kann.

Illustration 3: Jenkins Frontend

Anlegen von Testdaten


PHPUnit bietet bereits standardmig ber sogenannte Data Providers [4] die Mglichkeit, einen Test mit unterschiedlichen Datenstrukturen auszufhren. Hierzu kann ber die Annotation @dataProvider eine Methode deklariert werden, die ein Array oder einen Iterator mit den zu testenden Daten zurckgibt. Die Signatur der zu testenden Methode muss dann analog Listing 4 abhngig von der Datenstruktur die entsprechenden Parameter enthalten.
01 /** 02 * @dataProvider getHelperDataProvider 03 */ 04 public function testGetHelper($inputHelperName, $expectedClass) { 05 06 } 07 08 /** 09 * Data provider to run test with several data sets. 10 * 11 * @return void 12 */ 13 public function getHelperDataProvier() { 14 15 16 17 18 } Listing 4: Data Provider per Annotation ); return array( 'class name' => array('core/data', 'Mage_Core_Helper_Data'), 'module name' => array('core', 'Mage_Core_Helper_Data') $this->assertInstanceOf($expectedClass, $this->_model->getHelper($inputHelperName));

TechDivision GmbH

PHPUnit Tests mit Magento

Speziell fr das Ausfhren der Integrationstests sind jedoch fast immer Testdaten notwendig, die sich nicht einfach ber eine CSV-Datei oder ein Array darstellen lassen. Wie bereits zuvor erwhnt, stellt die Testsuite hierfr ber die zustzlichen Annotations auf Methodenebene @magentoDataFixture @magentoCongFixture Funktionen zur Verfgung, mit denen die fr jeweiligen Test erforderlichen Daten bequem angelegt und nach dem Test automatisch wieder gelscht werden. Somit ist
01 /**

sichergestellt, dass die Datenbank vor jedem Test in ihren Ausgangszustand zurckversetzt wird. Um dies so efzient wie mglich zu gestalten, werden die ber die jeweilige Annotation spezizierten Daten im Rahmen einer Transaktion angelegt, dann der Test ausgefhrt und die Transaktion mit einem Rollback zurckgesetzt. Die Datenbank wird somit zu keinem Zeitpunkt verndert, da tatschlich nie ein Commit fr die Transaktion erfolgt. Fr die Annotation @magentoDataFixture muss, wie in Listing 5 gezeigt, ein relativer Pfad zur Datei ausgehend vom Basisverzeichnis der jeweiligen Testsuite angegeben werden, z. B.

02 * @magentoDataFixture Mage/Catalog/_files/product_simple.php 03 */ 04 public function testSomething() { 20 } Listing 5: Annotation zum Anlegen von Testdaten

Innerhalb dieser Skripte kann die Anlage von Testdaten, wie in Listing 6 dargestellt, analog der Implementierung innerhalb eines Models vorgenommen werden.
01 $product = new Mage_Catalog_Model_Product(); 02 $product->setTypeId(Mage_Catalog_Model_Product_Type::TYPE_SIMPLE) 03 04 50 ->setId(1) ->setAttributeSetId(4) ->save();

Listing 6: Skript zum Anlegen von Testdaten

TechDivision GmbH

PHPUnit Tests mit Magento

Probleme beim Einsatz der Testsuite


Beim Einsatz der Testsuite im tglichen Entwicklungsprozess hat sich eine Vielzahl von Problemen gezeigt, die ohne deren Einsatz nicht auffallen wrden. Whrend der berarbeitung hat sich gezeigt, dass sich die Entwickler der Testsuite, auf jeden Fall bis zum Zeitpunkt der Portierung, noch nicht mit allen Aspekten des Testens auseinandergesetzt hatten. Nachfolgend mchte ich auf die, aus meiner Sicht, grten Probleme bei der Portierung etwas detaillierter eingehen. Aufteilung von Installations- und Datenskripten So werden z. B. hug die Installations- und Datenskripte nicht entsprechend den von Magento gemachten Vorgaben Installationskripte im Verzeichnis sql, Datenskripte im Verzeichnis data getrennt abgelegt. Erfolgt keine Trennung, so kommt es, da Magento im ersten Schritt nur die Tabellen anlegt und keine Daten einspielt, bei Erstellung der Testdatenbank durch die Testsuite zu Fehlern. So treten z. B. bei Installation einer Extension ohne diese Trennung, bei der Verknpfungen der Daten zur Steuertabelle angelegt werden sollen, zwangslug CONSTRAINT-Probleme auf, da die Steuerdaten zu diesem Zeitpunkt eben aufgrund der Trennung noch nicht existieren. Die Trennung in Installations- und Datenskripten alleine trgt zwar an sich bereits zur Vermeidung von Problemen bei, reicht jedoch noch nicht aus. Zustzlich ist es zwingend erforderlich, in der entsprechenden Kongurationsdatei unter app/etc/modules Abhngigkeiten zu anderen Extensions, auch zu Core-Modulen, zu hinterlegen. Anhand dieser Abhngigkeiten wird bei der Installation der Testdatenbank durch die Testsuite die Reihenfolge, in der die Installations- und Datenskripte ausgefhrt werden, festgelegt. Nur so kann sichergestellt werden, dass eine bentigte Tabelle oder deren Daten vor dem Ausfhren des Installations- oder Datenskripts auch tatschlich vorhanden ist.

Lokalisierungen Ein weiteres Problem ergibt sich aufgrund der Lokalisierung von Projekten. Die von Magento erstellte Testsuite fr Magento 2 geht, wie in Listing 7 gezeigt, davon aus, dass die Testdatenbank fr die USA lokalisiert ist. So wird in diversen Tests auf fest hinterlegte Werte wie z. B. auf Preise in USD geprft.
1 $this->assertEquals('<span class="price">$10.00</span>', $this->_model->getFormatedPrice()); Listing 7: Fest hinterlegte Werte in Magento 2 Tests

Nachdem Extensions wie z. B. TechDivision_GermanTax ber die Installations- und Datenskripte die Lokalisierung der Datenbank entsprechend anpassen, schlagen diese Tests fehl. Um dieses Problem zu lsen, mssen, wie in Listing 8 gezeigt, die fest hinterlegten Werte entsprechend der im jeweiligen Shop kongurierten Locale lokalisiert und erst dann geprft werden.
01 $formattedPrice = Mage::app()->getStore()->formatPrice(0.00, false); 02 $this->assertEquals('<span class="price">' . $formattedPrice . '</span>', $this->_model->getFormatedPrice()); Listing 8: Auf lokalisierte Werte testen

TechDivision GmbH

PHPUnit Tests mit Magento

Integration von Drittanbieter-Extensions DER FOLGENDE SATZ IST AUCH KAPUTT, DAS MIT DEM NEBEN FUNKTIONIERT SO NICHT Neben Abhngigkeiten von Extensions hat sich im Laufe der Einfhrung gezeigt, dass bei der Integration von Drittanbieter-Extensions die Magento Core Tests in vielen Fllen fehlschlagen, da diese durch das berschreiben von Core-Klassen die ursprngliche Funktionalitt verndern. Grundstzlich lsst sich diese Problem auf drei Arten lsen. Die erste und beste Mglichkeit ist natrlich der gnzliche Verzicht auf Rewrites, das Problem stellt sich somit gar nicht erst. Die zweite Mglichkeit, die immer dann verwendet werden sollte, wenn die Verwendung eines Rewrites unumgnglich ist, erlaubt dem Entwickler, die Extension per Konguration ber die Systemsteuerung zu aktivieren. Die Core Tests schlagen somit nicht fehl, da die Extension zuerst ber die Annotation @magentoCongFixture aktiviert werden muss. Die dritte und letzte Mglichkeit erlaubt dem Entwickler, einen Core Test durch die zustzlich eingefhrte Annotation @magentoRewriteTestMethod zu ersetzten. So wrde die Methode des in Listing 9 gezeigten DocBlocks z. B. den Core Test MageTest::testGetModel() ersetzen. Abhngigkeiten von Extensions Lokalisierung und Drittanbieter-Extensions stellen sicherlich nicht zu unterschtzende Probleme dar, die jedoch relativ leicht in den Griff zu bekommen sind. Als deutlich komplizierteres Problem hat sich die Abhngigkeit von Extensions beim Ausfhren der Testsuite gezeigt. Abhngigkeiten zum Magento Core spielen natrlich nur eine untergeordnete Rolle (siehe ). Hat eine Extension jedoch eine oder gar mehrere Abhngigkeit zu anderen oder Drittanbieter-Extensions, so mssen beim Aufruf der

Testsuite diese ebenfalls vorhanden sein. Magento hat zwar einen Mechanismus, einer Extension mitzuteilen, dass diese von einer oder mehreren anderen abhngig ist, allerdings werden bei der Installation abhngige Extensions nicht automatisch mitinstalliert. Die Lsung dieses Problems ist in diesem Fall abhngig vom eingesetzten Buildtool und vom Paketmanagement, in unserem Fall also ANT und PEAR [5]. Fr jedes PEAR-Paket lassen sich Abhngigkeiten denieren, die bei der Installation sicherstellen, dass bentigte Pakete auf jeden Fall vorhanden sind. Beim Aufruf eines der ANT Targets (siehe ) zum Ausfhren der Testsuite wird, falls nicht bereits vorhanden, automatisiert eine neue Magento-Instanz angelegt und ein fr jede Instanz separater PEAR Channel initialisiert. Anschlieend wird lokal ein PEAR-Paket aus der aktuellsten Version der Sourcen erzeugt und ber den zuvor initialisierten PEAR Channel installiert. Bentigt das Paket andere Pakete, so werden diese ber die im PEAR-Paket denierten Abhngigkeiten ebenfalls mitinstalliert. Somit wird vor dem Aufruf der Testsuite eine konsistente Testumgebung aufgebaut, die sicherstellt, dass alle zur Ausfhrung der Tests bentigten Sourcen in der Testinstanz vorhanden sind. Vielleicht haben Sie sich zuvor gefragt, warum wir auch Drittanbieter-Extensions im Rahmen von Projekten in unseren Build- und Deploymentprozess integrieren. Die Antwort darauf lautet, dass in vielen Projekten aus Efzienzund Konstengrnden Drittanbieter-Extensions verwendet werden, deren Funktionalitt jedoch fast immer erweitert werden muss. In den meisten Fllen wird hierzu, eine weitere, abhngige Extension implementiert, um bei einem Update der Extension Probleme zu vermeiden. Wie zuvor beschrieben, ist es fr den Einsatz der Testsuite notwendig, die Drittanbieter-Extension ebenfalls zu installieren, genau das lsst sich jedoch nur erreichen, wenn diese auch in den eigenen Build- und Deploymentprozess integriert ist.

01 /** 02 * @magentoRewriteTestMethod MageTest::testGetModel() 03 */ 04 public function testGetModel() { ... 20 } Listing 9: Ersetzen eines Core Tests ...

TechDivision GmbH

PHPUnit Tests mit Magento

10

Fazit
Trotz der aktuell noch relativ geringen Testabdeckung, hat bereits die Einfhrung der Testsuite zu einer erheblichen Verbesserung der Qualitt beigetragen. So konnten schon whrend der Migration zahlreiche im herkmmlichen Betrieb nicht sichtbare Probleme erkannt und beseitigt werden. Durch die Einfhrung und die tgliche Arbeit mit der Testsuite und die Umstellung auf SCRUM wurden die Entwickler fast ber Nacht zur nderung ihrer Arbeitsweise hin zu TDD gezwungen. Hierdurch entstanden zwar im ersten Schritt zustzliche Aufwnde in Form von Einarbeitung, Workshops und dem Schreiben von Tests, jedoch zeigt sich bereits nach kurzer Zeit, dass die Qualitt und damit auch die Kundenzufriedenheit proportional zu den Aufwnden steigt. Der aktuelle Stand der Testsuite kann ber das Github Repository [6] der TechDivision GmbH heruntergeladen und kostenfrei in eigenen Projekte eingesetzt werden. Da aus Kompatibilittsgrnden derzeit noch zahlreiche Tests deaktiviert wurden, freuen wir uns natrlich ber Untersttzung aus der Community, um alle sinnvollen Tests aus Magento 2 zu portieren und eine mglichst groe Testabdeckung zu erreichen.

Links & Literatur [1] https://wiki.magento.com/display/MAGE2DOC/Magento+Automated+Testing+Guide [2] http://www.phpunit.de [3] http://ant.apache.org [4] http://www.phpunit.de/manual/3.6/en/writing-tests-for-phpunit.html#writing-tests-for-phpunit.data-providers [5] http://pear.php.net [6] http://www.github.com/techdivision/TechDivision_MagentoUnitTesting

ber uns:
TechDivision ist ein etablierter E-Commerce Solution Partner und untersttzt seit vielen Jahren nationale und internationale Kunden in der integrierten Planung, Design und Implementierung von komplexen E-CommerceLsungen. Als Magento Gold Partner von Anfang an, gehrt TechDivision zu den fhrenden Magento Solution Partner in Europa. Mittelgroe Kunden und internationale Unternehmen wie WMF oder Ritter-Sport, vertrauen in die Kompetenz und Erfahrung von TechDivision. Derzeit hat TechDivision zwei Standorte in Rosenheim / Kolbermoor und Mnchen. Weitere Informationen ber TechDivision: www.techdivision.com

TechDivision GmbH Spinnereiinsel 3a 83059 Kolbermoor Telefon +49 8031 2210 55 - 0 Telefax +49 8031 2210 55 - 22 Redaktionell Verantwortlicher: Josef Willkommer E-Mail: info@techdivision.com www.techdivision.com

TechDivision GmbH

PHPUnit Tests mit Magento

11