PHPUnit Tests mit MagentoIst der Einsatz der Magento 2 Testsuite in Magento möglich? Und wie läuft die Portierung?Index:Mö...
Magento stellt seinen Entwicklungspartnernkünftig die Testsuite und den MagentoAutomated Testing Guide [1] zur Verfügung.E...
Portierung der TestsuiteAufbauend auf unserem Build- und Deploymentprozess, beidem der Entwickler die Möglichkeit hat, übe...
Überarbeitung der TestsZu den notwendigen Anpassungen zählten dieÜberarbeitung des Bootstrappings, auf das wir später noch...
Die Testsuite erzeugt vor dem Ausführen der Tests eineSandbox. Hierzu werden alle globalen sowie die in denExtensions enth...
Illustration 2: Integrationstests auf Kommandozeile starten6TechDivision GmbHLaufen die Tests ohne Fehler durch, wird das ...
Illustration 3: Jenkins Frontend7TechDivision GmbHPHPUnit bietet bereits standardmäßig über sogenannte Data Providers [4] ...
8TechDivision GmbHSpeziell für das Ausführen der Integrationstests sind jedochfast immer Testdaten notwendig, die sich nic...
9TechDivision GmbHLokalisierungenEin weiteres Problem ergibt sich aufgrund der Lokalisierung von Projekten. Die von Magent...
10TechDivision GmbHIntegration von Drittanbieter-ExtensionsDER FOLGENDE SATZ IST AUCH KAPUTT, DAS MIT DEMNEBEN FUNKTIONIER...
11TechDivision GmbHLinks & Literatur[1] https://wiki.magento.com/display/MAGE2DOC/Magento+Automated+Testing+Guide[2] http:...
Nächste SlideShare
Wird geladen in …5
×

PHP Unit Tests mit Magento

1.178 Aufrufe

Veröffentlicht am

Eine der größten Schwächen von Magento, wenn man im Vergleich zu anderen Shopsystemen überhaupt von Schwächen sprechen kann, besteht sicherlich im Fehlen einer PHPUnit-Testsuite analog der, die mit Magento 2 eingeführt wird. Da seitens Magento momentan kein finaler Fertigstellungstermin für Magento 2 genannt wurde, wird Magento sicherlich noch länger als ursprünglich erwartet für 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 Basisfunktionalität von Magento mit Unit- und Integrationsstest automatisiert testbar macht. Zusätzlich sollen natürlich auch die eigenen Entwicklungen für sich
sowie in Abhängigkeit der Basisfunktionalität testbar sein. Sieht man sich die Testsuite von Magento 2 etwas detaillierter an, ist gut erkennbar, in welche Richtung Magento hier künftig gehen wird. Nachdem die Qualität für die Solution Partner als eines der zentralen Kriterien in die Bewertung des Partners mit einfließt, stellt Magento seinen Entwicklungspartnern künftig mit der Testsuite und dem Magento Automated Testing Guide [1] die Tools für die notwendige Verbesserung der Qualität, und somit auch der Partnerbewertung durch Magento, zur Verfügung.
Dieser Artikel beschreibt die notwendigen Schritte zur Migration der Testsuite von Magento 2 auf Magento und zeigt anhand von Beispielen diverse Einsatzmöglichkeiten sowie die mögliche Integration in einen Build- und Deploymentprozess.

Veröffentlicht in: Technologie
0 Kommentare
1 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
1.178
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
3
Aktionen
Geteilt
0
Downloads
7
Kommentare
0
Gefällt mir
1
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

PHP Unit Tests mit Magento

  1. 1. PHPUnit Tests mit MagentoIst der Einsatz der Magento 2 Testsuite in Magento möglich? Und wie läuft die Portierung?Index:Mögliche TestverfahrenPortierung der TestsuiteAnlegen von TestdatenProbleme beim Einsatz der TestsuiteFazitwww.techdivision.com1TechDivision GmbH PHPUnit Tests mit Magento
  2. 2. Magento stellt seinen Entwicklungspartnernkünftig die Testsuite und den MagentoAutomated Testing Guide [1] zur Verfügung.Eine der größten Schwächen von Magento, wenn man imVergleich zu anderen Shopsystemen überhaupt vonSchwächen sprechen kann, besteht sicherlich im Fehleneiner PHPUnit-Testsuite analog der, die mit Magento 2eingeführt wird. Da seitens Magento momentan kein finalerFertigstellungstermin für Magento 2 genannt wurde, wirdMagento sicherlich noch länger als ursprünglich erwartet fürProjekte zum Einsatz kommen. Anscheinend wird dem auchseitens Magento Rechnung getragen, da sich seit VersionCE 1.7.x sowie EE 1.12.x auch hinsichtlich der Testbarkeitmit PHPUnit einiges getan hat.Jeder Entwickler, der mit Magento arbeitet, vermisstsicherlich schmerzlich eine Testsuite, die dieBasisfunktionalität von Magento mit Unit- undIntegrationsstest automatisiert testbar macht. Zusätzlichsollen natürlich auch die eigenen Entwicklungen für sichsowie in Abhängigkeit der Basisfunktionalität testbar sein.Sieht man sich die Testsuite von Magento 2 etwasdetaillierter an, ist gut erkennbar, in welche RichtungMagento hier künftig gehen wird. Nachdem die Qualität fürdie Solution Partner als eines der zentralen Kriterien in dieBewertung des Partners mit einfließt, stellt Magento seinenEntwicklungspartnern künftig mit der Testsuite und demMagento Automated Testing Guide [1] die Tools für dienotwendige Verbesserung der Qualität, und somit auch derPartnerbewertung durch Magento, zur Verfügung.Dieser Artikel beschreibt die notwendigen Schritte zurMigration der Testsuite von Magento 2 auf Magento undzeigt anhand von Beispielen diverse Einsatzmöglichkeitensowie die mögliche Integration in einen Build- undDeploymentprozess.von Tim WagnerDie Testsuite bringt Tests für die gängigsten vierTestverfahren mit. So werden Unit-, Integrations- undPerformancetests ausgeliefert. Zusätzlich enthält die SuiteTests für die statische Code-Analyse. Bis auf diePerformance Tests bauen alle Tests auf PHPUnit [2] vonSebastian Bergmann auf. Dieser Artikel beschäftigt sichhauptsächlich mit den Unit- und den Integrationstests, dadiese für die meisten Entwickler die größte Bedeutunghaben. Durch die Integration dieser beiden Testverfahrenwird die Qualität und somit die auch Wartbarkeit vonMagento-Projekten mittel- und langfristig erheblich steigen.Auf die statische Code-Analyse möchte ich in diesem Artikelnicht näher eingehen, da diese im Rahmen des Build- undDeploymentprozesses separat abgehandelt werden kann,und sie zum anderen zum Migrationszeitpunkt nur sehrrudimentär seitens Magento implementiert war. Auch aufdie Performancetests wird nicht näher eingegangen, dadiese über JMeter umgesetzt und ebenfalls separataufgerufen werden müssen.Mögliche Testverfahren2TechDivision GmbH PHPUnit Tests mit Magento
  3. 3. Portierung der TestsuiteAufbauend auf unserem Build- und Deploymentprozess, beidem der Entwickler die Möglichkeit hat, über daseingesetzte Buildtool, in unserem Fall ANT [3], jederzeitautomatisiert eine neue Magento-Instanz zu erstellen, war,neben einer spürbaren Steigerung der Qualität, eines derPrimärziele der Portierung, dass beim Erstellen einer neuenEntwicklungsinstanz dem Entwickler die Tests umgehendzur Verfügung stehen und diese somit nahtlos in alleEntwicklungsprozesse integriert sind. Die Portierung erfolgtein drei Schritten und begann im April 2012.Schritt 1: Testsuite als Extension bereitstellenIm ersten Schritt wurden die zum Portierungszeitpunktaktuellen Sourcen von Magento 2 aus dem GIT Repositorygeclont. Anschließend wurde die Testsuite im Rahmen einereigenen Extension so aufgesetzt, dass sie zum einen injedem Magento-Shop ab Version CE 1.7.x/EE 1.12.xinstalliert, und zum anderen über einen automatisiertenProzess für jede zukünftige Magento-Version ein um dieTestsuite erweitertes Installationspaket erstellt und aufeinem Buildserver bereitgestellt werden kann.Die Extension enthält somit, wie in Illustration 1 dargestellt,neben der notwendigen Konfiguration und den Helper-Klassen im app-Verzeichnis den Bootstrapper (1), dieVerzeichnisse dev (2), das aus den Magento-2-Sourcenübernommen wurde, sowie die Verzeichnisse lib +downloader (5 + 3).Das lib-Verzeichnis enthält einige für Magento 2 spezifischeKlassen, die die Testsuite jedoch für die Initialisierungbenötigt. Im downloader-Verzeichnis befinden sich die vonfrüheren Magento-1-Versionen benötigten Dateien für denDownloader. Dieser wird zwar mit aktuellen Magento-Versionen nicht mehr ausgeliefert, jedoch für daserfolgreiche Erstellen des Code-Coverage-Reports benötigt.Magento referenziert hier in einigen Dateien immer nochfälschlicherweise PEAR-Klassen (4), die für den Betriebeigentlich nicht mehr benötigt werden. Bei der statischenCode-Analyse mit PHPUnit tritt jedoch ein Fatal Error auf,falls diese Klassen nicht im downloader-Verzeichnisgefunden werden können. Optional könnte auch über dieWhitelist in der phpunit.xml.dist auf die Prüfung derentsprechenden Sourcen durch PHPUnit beim Erstellen desCodeCoverage Reports verzichtet werden.Schritt 2: Anpassen der Testsuite an MagentoIm zweiten Schritt musste die mit Magento 2 ausgelieferteTestsuite an Magento angepasst werden. Zu Beginn derMigration hatten wir Magento CE 1.6.x/EE 1.11.x alsZielversion vorgegeben. Es stellte sich jedoch relativ schnellheraus, dass hierbei für den Einsatz des TestframeworksAnpassungen an den Magento-Core-Klassen notwendigwären. Ab Version CE 1.7.x/EE 1.12.x wurden dienotwendigen Anpassungen bereits von Magento direkt imCore vorgenommen, was Anpassungen für den Einsatz derTestsuite überflüssig macht.Illustration 1: Verzeichnisstruktur Testsuite3TechDivision GmbH PHPUnit Tests mit Magento
  4. 4. Überarbeitung der TestsZu den notwendigen Anpassungen zählten dieÜberarbeitung des Bootstrappings, auf das wir später nochnäher eingehen werden, sowie Anpassungen dereigentlichen Tests, wobei Letzteres aufgrund vonEinschränken in Magento zu den wesentlich aufwändigerenArbeiten gehörte.Aufgrund von Anpassungen der Architektur, hauptsächlichhinsichtlich Design und Layout, konnten viele Tests ausMagento 2 nicht 1:1 übernommen werden, da entwederVerzeichnisse und Dateien schlichtweg nicht vorhandenwaren, Methoden sich geändert hatten, oder gänzlich neuhinzugekommen waren.Eine unschöne Einschränkung von Magento hat sich bereitsbeim Überarbeiten der Tests gezeigt. So können dieAnnotations zum Anlegen von Testdaten (siehe ) in Magento2 entweder auf Klassen- oder Methodenebene angegebenwerden. Beim Einsatz mit Magento traten hierbei jedoch invielen Fällen Probleme hinsichtlich inkonsistenter Testdatenauf, die wohl auf Anpassungen in Magento 2 im Bereich derDatenbankschicht hindeuten. Die betroffenen Testfällemusste bei der Migration entsprechend überarbeitet, alsodie entsprechenden Annotationen auf Methodenebenegesetzt oder gar deaktiviert werden.Betroffene Testfälle, aktuell ca. 630, wurden nicht gelöscht,sondern vielmehr geskippt und werden nach und nachgeprüft und überarbeitet. Weiterhin wurden zum Zeitpunktder Portierung 27 Testfälle durch Magento als incompletedeklariert. Auch diese werden, falls sinnvoll, in künftigenVersionen der Testsuite fertiggestellt.Anpassen des BootstrappingsFür das Ausführen der Unit- und der Integrationstest wirddie Testsuite über einen Bootstrapper initialisiert. DerBootstrapper wird, wie in Listing 1 dargestellt, in derPHPUnit-Konfigurationsdatei phpunit.xml.dist registriert, erinitialisiert die Laufzeitumgebung zum Ausführen derTestsuite.01…50<phpunit bootstrap="./framework/bootstrap.php">...</phpunit>Listing 1: Konfiguration PHPUnit BootstrapperIm Fall der Unittests werden hier lediglich die Includepfadegesetzt, der Autoloader initialisiert und das Verzeichnis zurSpeicherung von temporären Dateien geleert.Für die Integrationstests ist hier wesentlich mehr Aufwandnotwendig, da eine Magento-Sandbox auf Basis deraktuellen Shopkonfiguration, sowie eine Testdatenbankerstellt werden muss. Außerdem erweitert Magento PHPUnitum zusätzliche Profilingmöglichkeiten und einige Observer,die das Schreiben von Tests für den Entwickler erheblichvereinfachen.So stehen über die durch die Testsuite zusätzlichebereitgestellten Annotations@magentoAppIsolation@magentoDataFixture@magentoConfigFixturedem Entwickler Funktionen zum automatisierten Anlegenvon Test- und Konfigurationsdaten sowie zur Ausführungeines einzelnen Tests in einer isolierten (zurückgesetzten)Instanz zur Verfügung.4TechDivision GmbH PHPUnit Tests mit Magento
  5. 5. Die Testsuite erzeugt vor dem Ausführen der Tests eineSandbox. Hierzu werden alle globalen sowie die in denExtensions enthaltenen Konfigurationsdateien in eintemporäres Sandbox-Verzeichnis unterhalb der jeweiligenTestsuite kopiert. Auf Basis der dort erstelltenVerzeichnisstruktur wird der Shop während desBootstrappings initialisiert. Da für die Tests Anpassungen anden Konfigurationsdateien notwendig sind, stellt diesesVerfahren sicher, dass für die Ausführung der Tests keinerleiVeränderungen am Shop vorgenommen und diesevollkommen isoliert und ohne Nebeneffekte vom Livesystemausgeführt werden.Local- vs. DistributiontestingWährend der Einführungsphase hat sich gezeigt, dass esaus Zeitgründen in der Praxis nicht möglich ist, bei jedemlokalen Build alle Tests laufen zu lassen. Auf einem gutausgestatteten Entwicklungsrechner dauert der Durchlaufder gesamten Testsuite einschließlich des Code CoverageReports bereits über 15 Minuten. Hinzu kommen noch dieTests der jeweilige Extension. Für die lokale Entwicklung undfür die Erstellung einer neuen Paketversion steht neben derStandard-Konfigurationsdatei phpunit.xml.dist, die alle Testsausführt (Distributiontesting), noch eine Konfigurationsdateiphpunit.xml.local zur Verfügung, die nur die Tests imNamespace der aktuellen Extension ausführt (Localtesting).Heißt die Extension z. B. TechDivision_GermanTax, sowerden beim Aufruf der Tests unter Verwendung derKonfigurationsdatei phpunit.xml.local alle Tests unterhalbdes Verzeichnisses dev/tests/integration/testsuite/TechDivision durchlaufen und der Code Coverage Reportausschließlich für alle Dateien der jeweiligen Extensionerstellt, was, abhängig von der Anzahl der Tests, zu einererheblichen Zeiteinsparung führt.Schritt 3: Integration in den EntwicklungsprozessMit die größte Herausforderung der Portierung war der dritteund somit letzte Schritt: Die Integration in denEntwicklungsprozess. Mit Magento 2 werden die Testsuiteund die Tests standardmäßig ausgeliefert. Die Sourcen vonMagento hingegen kommen natürlich ohne Testsuite. Umeine möglichst nahtlose und einfache Integration zugewährleisten, wurden zur lokalen Entwicklung eingesetzteMagento-Pakete um die Testsuite erweitert. So können dieTests zum einen über ein ANT-Target jederzeit aus derlokalen Entwicklungsumgebung heraus gestartet werden,zum anderen kann beim Build noch vor dem Erstellen desPakets sichergestellt werden, dass das Paket erst dannerstellt wird, wenn alle Tests fehlerfrei durchlaufen wurden.Hierbei kann der Entwickler durch Aufruf der verschiedenenANT-Targets zu jedem Zeitpunkt entscheiden, welcheTestfälle, also Unit- und/oder Integrationstests, ausgeführtwerden sollen. Zusätzlich besteht die Möglichkeit, über BuildProperties zu definieren, ob nur die jeweiligen Tests deraktuell zu entwickelnden Extension oder zusätzlich auch dieCore Tests ausgeführt werden sollen.Für den Build- und Deployment Prozess können Tools wiePhing oder, wie in unserem Fall, ANT verwendet werden.Zum Ausführen der Test stehen die in Listing 2 aufgeführtenTargets zur Verfügung.010203phpunit-run-all-testsphpunit-run-unit-testsphpunit-run-integration-testsListing 2: ANT Targets zur Ausführung der Unit TestsDas ANT-Target phpunit-run-integration-tests startet, wieder Name schon sagt, die Integrationtests der Testsuite. Inder aktuellen Version werden derzeit 1.950 Testsausgeführt, wobei davon, wie bereits zuvor beschreiben,wegen Inkompatibilitäten mit Magento noch 628 geskipptwerden und 27 incomplete sind. Die aktuelle Testsuite mit2.990 Assertions deckt ca. 11 % der Magento-Core-Klassen ab, sprich noch knapp 90 % des Magento-Quelltexts sind nicht durch Tests abgedeckt.Diese Targets können entweder direkt aus der lokalenEntwicklungsumgebung oder automatisch während desBuilds durch den CI Server ausgeführt werden. Über dieBuild Properties (siehe Listing 3) kann konfiguriert werden,ob und welche (Distribution oder Local) Tests während desBuilds ausgeführt werden sollen. Zusätzlich kannkonfiguriert werden, welche Datenbank für die Ausführungder Integrationstest verwendet werden soll, standardmäßigwird eine zusätzliche leere Datenbank erzeugt.5TechDivision GmbHTesten in der SandboxPHPUnit Tests mit Magento
  6. 6. Illustration 2: Integrationstests auf Kommandozeile starten6TechDivision GmbHLaufen die Tests ohne Fehler durch, wird das Paket erstelltund automatisch im PEAR Channel hinterlegt.Selbstverständlich muss nicht zwingend PEAR für dasPaketmanagement verwendet werden, PEAR hat sichallerdings in den letzten Jahren in unserem Fall bewährt.Aktuell wird ein Ersatz durch Composer geprüft.Um sicherzustellen, dass jede Extension für sich selbst,sowie im Zusammenspiel mit allen anderen Extensions imRahmen eines Projekts lauffähig ist, wird pro Extension undzusätzlich pro Projekt ein eigener Job im CI Server angelegt.Wird eine Änderung durch den Entwickler in das GITRepository der Extension gepusht, wird automatisch durchden CI Server der Build gestartet, die extensionspezifischeTestsuite ausgeführt und nach erfolgreichem Durchlauf einneues PEAR Paket mit der aktuellsten Version gebaut undauf dem Channel Server zur Verfügung gestellt. Vor demRelease eines Projekts werden alle Extensions in deraktuellsten Version installiert und alle Tests – Core undExtension – ausgeführt. Erst, wenn alle Tests über einProjekt erfolgreich durchlaufen, wird das neue Release zumDeployment freigegeben.Über das Jenkins Frontend (Illustration 3) haben ScrumMaster und Product Owner bereits während des Sprints dieMöglichkeit, die verschiedene Metriken, sowie die Anzahlder erstellten Unit- und Integrationstests im Auge zubehalten. Nach Abschluss des Sprints gewährleisten dieTests, dass auch bei der Weiterentwicklung der Extensionoder des Shops die Qualität einfach und effektivsichergestellt werden kann.010203phpunit.tests.execute = falsephpunit.database = ${mysql.database}_testsphpunit.testsuite = distListing 3: Build Properties zur Konfiguration der ANT-TargetsIllustration 2 zeigt die Ausgabe der Kommandozeile nachdem Durchlauf der Integrationstests der aktuellen Versionder Testsuite.PHPUnit Tests mit Magento
  7. 7. Illustration 3: Jenkins Frontend7TechDivision GmbHPHPUnit bietet bereits standardmäßig über sogenannte Data Providers [4] die Möglichkeit, einen Test mit unterschiedlichenDatenstrukturen auszuführen. Hierzu kann über die Annotation @dataProvider eine Methode deklariert werden, die ein Arrayoder einen Iterator mit den zu testenden Daten zurückgibt. Die Signatur der zu testenden Methode muss dann analog Listing 4abhängig von der Datenstruktur die entsprechenden Parameter enthalten.010203040506070809101112131415161718/*** @dataProvider getHelperDataProvider*/public function testGetHelper($inputHelperName, $expectedClass) {$this->assertInstanceOf($expectedClass, $this->_model->getHelper($inputHelperName));}/*** Data provider to run test with several data sets.** @return void*/public function getHelperDataProvier() {return array(class name => array(core/data, Mage_Core_Helper_Data),module name => array(core, Mage_Core_Helper_Data));}Listing 4: Data Provider per AnnotationAnlegen von TestdatenPHPUnit Tests mit Magento
  8. 8. 8TechDivision GmbHSpeziell für das Ausführen der Integrationstests sind jedochfast immer Testdaten notwendig, die sich nicht einfach übereine CSV-Datei oder ein Array darstellen lassen. Wie bereitszuvor erwähnt, stellt die Testsuite hierfür über diezusätzlichen Annotations auf Methodenebene@magentoDataFixture@magentoConfigFixtureFunktionen zur Verfügung, mit denen die für jeweiligen Testerforderlichen Daten bequem angelegt und nach dem Testautomatisch wieder gelöscht werden. Somit istsichergestellt, dass die Datenbank vor jedem Test in ihrenAusgangszustand zurückversetzt wird. Um dies so effizientwie möglich zu gestalten, werden die über die jeweiligeAnnotation spezifizierten Daten im Rahmen einerTransaktion angelegt, dann der Test ausgeführt und dieTransaktion mit einem Rollback zurückgesetzt. DieDatenbank wird somit zu keinem Zeitpunkt verändert, datatsächlich nie ein Commit für die Transaktion erfolgt.Für die Annotation @magentoDataFixture muss, wie inListing 5 gezeigt, ein relativer Pfad zur Datei ausgehend vomBasisverzeichnis der jeweiligen Testsuite angegebenwerden, z. B.01020304…20/*** @magentoDataFixture Mage/Catalog/_files/product_simple.php*/public function testSomething() {…}Listing 5: Annotation zum Anlegen von TestdatenInnerhalb dieser Skripte kann die Anlage von Testdaten, wie in Listing 6 dargestellt, analog der Implementierung innerhalbeines Models vorgenommen werden.01020304…50$product = new Mage_Catalog_Model_Product();$product->setTypeId(Mage_Catalog_Model_Product_Type::TYPE_SIMPLE)->setId(1)->setAttributeSetId(4)…->save();Listing 6: Skript zum Anlegen von TestdatenPHPUnit Tests mit Magento
  9. 9. 9TechDivision GmbHLokalisierungenEin weiteres Problem ergibt sich aufgrund der Lokalisierung von Projekten. Die von Magento erstellte Testsuite für Magento 2geht, wie in Listing 7 gezeigt, davon aus, dass die Testdatenbank für die USA lokalisiert ist. So wird in diversen Tests auf festhinterlegte Werte wie z. B. auf Preise in USD geprüft.1 $this->assertEquals(<span class="price">$10.00</span>, $this->_model->getFormatedPrice());Listing 7: Fest hinterlegte Werte in Magento 2 TestsNachdem Extensions wie z. B. TechDivision_GermanTax über die Installations- und Datenskripte die Lokalisierung derDatenbank entsprechend anpassen, schlagen diese Tests fehl. Um dieses Problem zu lösen, müssen, wie in Listing 8 gezeigt,die fest hinterlegten Werte entsprechend der im jeweiligen Shop konfigurierten Locale lokalisiert und erst dann geprüft werden.0102$formattedPrice = Mage::app()->getStore()->formatPrice(0.00, false);$this->assertEquals(<span class="price"> . $formattedPrice . </span>, $this->_model->getFormatedPrice());Listing 8: Auf lokalisierte Werte testenBeim Einsatz der Testsuite im täglichen Entwicklungsprozesshat sich eine Vielzahl von Problemen gezeigt, die ohne derenEinsatz nicht auffallen würden. Während der Überarbeitunghat sich gezeigt, dass sich die Entwickler der Testsuite, aufjeden Fall bis zum Zeitpunkt der Portierung, noch nicht mitallen Aspekten des Testens auseinandergesetzt hatten.Nachfolgend möchte ich auf die, aus meiner Sicht, größtenProbleme bei der Portierung etwas detaillierter eingehen.Aufteilung von Installations- und DatenskriptenSo werden z. B. häufig die Installations- und Datenskriptenicht entsprechend den von Magento gemachten Vorgaben– Installationskripte im Verzeichnis sql, Datenskripte imVerzeichnis data – getrennt abgelegt. Erfolgt keineTrennung, so kommt es, da Magento im ersten Schritt nurdie Tabellen anlegt und keine Daten einspielt, bei Erstellungder Testdatenbank durch die Testsuite zu Fehlern. So tretenz. B. bei Installation einer Extension ohne diese Trennung,bei der Verknüpfungen der Daten zur Steuertabelle angelegtwerden sollen, zwangsläufig CONSTRAINT-Probleme auf,da die Steuerdaten zu diesem Zeitpunkt eben aufgrund derTrennung noch nicht existieren.Die Trennung in Installations- und Datenskripten alleine trägtzwar an sich bereits zur Vermeidung von Problemen bei,reicht jedoch noch nicht aus. Zusätzlich ist es zwingenderforderlich, in der entsprechenden Konfigurationsdateiunter app/etc/modules Abhängigkeiten zu anderenExtensions, auch zu Core-Modulen, zu hinterlegen. Anhanddieser Abhängigkeiten wird bei der Installation derTestdatenbank durch die Testsuite die Reihenfolge, in derdie Installations- und Datenskripte ausgeführt werden,festgelegt. Nur so kann sichergestellt werden, dass einebenötigte Tabelle oder deren Daten vor dem Ausführen desInstallations- oder Datenskripts auch tatsächlich vorhandenist.Probleme beim Einsatz der TestsuitePHPUnit Tests mit Magento
  10. 10. 10TechDivision GmbHIntegration von Drittanbieter-ExtensionsDER FOLGENDE SATZ IST AUCH KAPUTT, DAS MIT DEMNEBEN FUNKTIONIERT SO NICHT Neben Abhängigkeiten vonExtensions hat sich im Laufe der Einführung gezeigt, dassbei der Integration von Drittanbieter-Extensions die MagentoCore Tests in vielen Fällen fehlschlagen, da diese durch dasÜberschreiben von Core-Klassen die ursprünglicheFunktionalität verändern. Grundsätzlich lässt sich dieseProblem auf drei Arten lösen.Die erste und beste Möglichkeit ist natürlich der gänzlicheVerzicht auf Rewrites, das Problem stellt sich somit gar nichterst.Die zweite Möglichkeit, die immer dann verwendet werdensollte, wenn die Verwendung eines Rewrites unumgänglichist, erlaubt dem Entwickler, die Extension per Konfigurationüber die Systemsteuerung zu aktivieren. Die Core Testsschlagen somit nicht fehl, da die Extension zuerst über dieAnnotation @magentoConfigFixture aktiviert werden muss.Die dritte und letzte Möglichkeit erlaubt dem Entwickler,einen Core Test durch die zusätzlich eingeführte Annotation@magentoRewriteTestMethod zu ersetzten. So würde dieMethode des in Listing 9 gezeigten DocBlocks z. B. denCore Test MageTest::testGetModel() ersetzen.Abhängigkeiten von ExtensionsLokalisierung und Drittanbieter-Extensions stellen sicherlichnicht zu unterschätzende Probleme dar, die jedoch relativleicht in den Griff zu bekommen sind. Als deutlichkomplizierteres Problem hat sich die Abhängigkeit vonExtensions beim Ausführen der Testsuite gezeigt.Abhängigkeiten zum Magento Core spielen natürlich nureine untergeordnete Rolle (siehe ). Hat eine Extension jedocheine oder gar mehrere Abhängigkeit zu anderen oderDrittanbieter-Extensions, so müssen beim Aufruf derTestsuite diese ebenfalls vorhanden sein. Magento hat zwareinen Mechanismus, einer Extension mitzuteilen, dass diesevon einer oder mehreren anderen abhängig ist, allerdingswerden bei der Installation abhängige Extensions nichtautomatisch mitinstalliert. Die Lösung dieses Problems ist indiesem Fall abhängig vom eingesetzten Buildtool und vomPaketmanagement, in unserem Fall also ANT und PEAR [5].Für jedes PEAR-Paket lassen sich Abhängigkeitendefinieren, die bei der Installation sicherstellen, dassbenötigte Pakete auf jeden Fall vorhanden sind.Beim Aufruf eines der ANT Targets (siehe ) zum Ausführender Testsuite wird, falls nicht bereits vorhanden,automatisiert eine neue Magento-Instanz angelegt und einfür jede Instanz separater PEAR Channel initialisiert.Anschließend wird lokal ein PEAR-Paket aus der aktuellstenVersion der Sourcen erzeugt und über den zuvorinitialisierten PEAR Channel installiert. Benötigt das Paketandere Pakete, so werden diese über die im PEAR-Paketdefinierten Abhängigkeiten ebenfalls mitinstalliert. Somitwird vor dem Aufruf der Testsuite eine konsistenteTestumgebung aufgebaut, die sicherstellt, dass alle zurAusführung der Tests benötigten Sourcen in der Testinstanzvorhanden sind.Vielleicht haben Sie sich zuvor gefragt, warum wir auchDrittanbieter-Extensions im Rahmen von Projekten inunseren Build- und Deploymentprozess integrieren. DieAntwort darauf lautet, dass in vielen Projekten aus Effizienz-und Konstengründen Drittanbieter-Extensions verwendetwerden, deren Funktionalität jedoch fast immer erweitertwerden muss. In den meisten Fällen wird hierzu, eineweitere, abhängige Extension implementiert, um bei einemUpdate der Extension Probleme zu vermeiden. Wie zuvorbeschrieben, ist es für den Einsatz der Testsuite notwendig,die Drittanbieter-Extension ebenfalls zu installieren, genaudas lässt sich jedoch nur erreichen, wenn diese auch in deneigenen Build- und Deploymentprozess integriert ist.01020304...20/*** @magentoRewriteTestMethod MageTest::testGetModel()*/public function testGetModel() {...}Listing 9: Ersetzen eines Core TestsPHPUnit Tests mit Magento
  11. 11. 11TechDivision GmbHLinks & 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_MagentoUnitTestingTrotz der aktuell noch relativ geringen Testabdeckung, hatbereits die Einführung der Testsuite zu einer erheblichenVerbesserung der Qualität beigetragen. So konnten schonwährend der Migration zahlreiche im herkömmlichen Betriebnicht sichtbare Probleme erkannt und beseitigt werden.Durch die Einführung und die tägliche Arbeit mit derTestsuite und die Umstellung auf SCRUM wurden dieEntwickler fast über Nacht zur Änderung ihrer Arbeitsweisehin zu TDD gezwungen. Hierdurch entstanden zwar imersten Schritt zusätzliche Aufwände in Form vonEinarbeitung, Workshops und dem Schreiben von Tests,jedoch zeigt sich bereits nach kurzer Zeit, dass die Qualitätund damit auch die Kundenzufriedenheit proportional zu denAufwänden steigt.Der aktuelle Stand der Testsuite kann über das GithubRepository [6] der TechDivision GmbH heruntergeladen undkostenfrei in eigenen Projekte eingesetzt werden. Da ausKompatibilitätsgründen derzeit noch zahlreiche Testsdeaktiviert wurden, freuen wir uns natürlich überUnterstützung aus der Community, um alle sinnvollen Testsaus Magento 2 zu portieren und eine möglichst großeTestabdeckung zu erreichen.FazitÜber uns:TechDivision ist ein etablierter E-Commerce Solution Partner und unterstützt seit vielen Jahren nationale undinternationale Kunden in der integrierten Planung, Design und Implementierung von komplexen E-Commerce-Lösungen. Als Magento Gold Partner von Anfang an, gehört TechDivision zu den führenden Magento Solution Partnerin Europa. Mittelgroße Kunden und internationale Unternehmen wie WMF oder Ritter-Sport, vertrauen in dieKompetenz und Erfahrung von TechDivision.Derzeit hat TechDivision zwei Standorte in Rosenheim / Kolbermoor und München.Weitere Informationen über TechDivision: www.techdivision.comTechDivision GmbHSpinnereiinsel 3a83059 KolbermoorTelefon +49 8031 2210 55 - 0Telefax +49 8031 2210 55 - 22Redaktionell Verantwortlicher:Josef WillkommerE-Mail: info@techdivision.comwww.techdivision.comPHPUnit Tests mit Magento

×