Die Magento 2 Testsuite in Magento 1 portieren

Test: gut!
Kommentare

Eine der größten Schwächen von Magento 1, 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 1 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 1 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 zur 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 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 1 und zeigt anhand von Beispielen diverse Einsatzmöglichkeiten sowie die mögliche Integration in einen Build- und Deployment-Prozess.

Mögliche Testverfahren

Die Testsuite bringt Tests für die gängigsten vier Testverfahren mit. So werden Unit, Integrations- und Performancetests ausgeliefert. Zusätzlich enthält die Suite Tests für die statische Codeanalyse. Bis auf die Performancetests bauen alle Tests auf PHPUnit [2] von Sebastian Bergmann auf. Dieser Artikel beschäftigt sich hauptsächlich mit den Unit und den Integrationstests, da diese für die meisten Entwickler die größte Bedeutung haben. Durch die Integration dieser beiden Testverfahren werden die Qualität und somit auch die Wartbarkeit von Magento-Projekten mittel- und langfristig erheblich steigen. Auf die statische Codeanalyse möchte ich in diesem Artikel nicht näher eingehen, da diese im Rahmen des Build- und Deployment-Prozesses separat abgehandelt werden kann und sie zum anderen zum Migrationszeitpunkt nur sehr rudimentär seitens Magento implementiert war. Auch auf die Performancetests wird nicht näher eingegangen, da diese über JMeter umgesetzt und ebenfalls separat aufgerufen werden müssen.

Portierung der Testsuite

Bei unserem Build- und Deployment-Prozess hat der Entwickler die Möglichkeit, über das eingesetzte Build-Tool, in unserem Fall Ant [3], jederzeit automatisiert eine neue Magento-Instanz zu erstellen. Neben einer spürbaren Steigerung der Qualität, war eines der Primärziele der Portierung, dass dem Entwickler beim Erstellen einer neuen Entwicklungsinstanz die Tests umgehend zur Verfügung 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 geklont. Anschließend 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 für jede zukünftige Magento-Version ein um die Testsuite erweitertes Installationspaket erstellt und auf einem Build-Server bereitgestellt werden kann.

Die Extension enthält somit, wie in Abbildung 1 dargestellt, neben der notwendigen Konfiguration und den Helper-Klassen im app-Verzeichnis den Bootstrapper (1), die Verzeichnisse dev (2), das aus den Magento-2-Sourcen übernommen wurde, sowie die Verzeichnisse lib und downloader (5 und 3).

Abb. 1: Verzeichnisstruktur-Testsuite

Das lib-Verzeichnis enthält einige für Magento 2 spezifische Klassen, die die Testsuite jedoch für die Initialisierung benötigt. Im downloader-Verzeichnis befinden sich die von früheren Magento-1-Versionen benötigten Dateien für den Downloader. Dieser wird zwar mit aktuellen Magento-Versionen nicht mehr ausgeliefert, jedoch für das erfolgreiche Erstellen des Code-Coverage-Reports benötigt. Magento 1 referenziert hier in einigen Dateien immer noch fälschlicherweise PEAR-Klassen (4), die für den Betrieb eigentlich nicht mehr benötigt werden. Bei der statischen Codeanalyse mit PHPUnit tritt jedoch ein Fatal Error auf, falls diese Klassen nicht im downloader-Verzeichnis gefunden werden können. Optional könnte auch über die Whitelist in der phpunit.xml.dist auf die Prüfung der entsprechenden Sourcen durch PHPUnit beim Erstellen des Code-Coverage-Reports verzichtet werden.

Schritt 2: Anpassen der Testsuite an Magento 1

Im zweiten Schritt musste die mit Magento 2 ausgelieferte Testsuite an Magento 1 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 für den Einsatz des Testframeworks Anpassungen an den Magento-Core-Klassen notwendig wären. Ab Version CE 1.7.x/EE 1.12.x wurden die notwendigen Anpassungen bereits von Magento direkt im Core vorgenommen, was Anpassungen für den Einsatz der Testsuite überflüssig macht.

Überarbeitung der Tests

Zu den notwendigen Anpassungen zählten die Überarbeitung des Bootstrappings, auf das wir später noch näher eingehen werden, sowie Anpassungen der eigentlichen Tests, wobei Letzteres aufgrund von Einschränkungen in Magento 1 zu den wesentlich aufwändigeren Arbeiten gehörte.

Aufgrund von Anpassungen der Architektur, hauptsächlich 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 geändert hatten, oder gänzlich neu hinzugekommen waren.

Eine unschöne Einschränkung von Magento 1 hat sich bereits beim Überarbeiten der Tests gezeigt. So können die Annotations zum Anlegen von Testdaten (siehe „Anlegen von Testdaten“) in Magento 2 entweder auf Klassen- oder Methodenebene angegeben werden. Beim Einsatz mit Magento 1 traten hierbei jedoch in vielen Fällen Probleme hinsichtlich inkonsistenter Testdaten auf, die wohl auf Anpassungen in Magento 2 im Bereich der Datenbankschicht hindeuten. Die betroffenen Testfälle musste bei der Migration entsprechend überarbeitet, also die entsprechenden Annotationen auf Methodenebene gesetzt oder gar deaktiviert werden.

Betroffene Testfälle, aktuell ca. 630, wurden nicht gelöscht, sondern vielmehr geskippt und werden nach und nach geprüft und überarbeitet. Weiterhin wurden zum Zeitpunkt der Portierung 27 Testfälle durch Magento als incomplete deklariert. Auch diese werden, falls sinnvoll, in künftigen Versionen der Testsuite fertiggestellt.

Anpassen des Bootstrappings

Für das Ausführen der Unit und der Integrationstests wird die Testsuite über einen Bootstrapper initialisiert. Der Bootstrapper wird, wie folgend dargestellt, in der PHPUnit-Konfigurationsdatei phpunit.xml.dist registriert. Er initialisiert die Laufzeitumgebung zum Ausführen der Testsuite.

 ...

Im Fall der Unit Tests werden hier lediglich die Include-Pfade gesetzt, der Autoloader initialisiert und das Verzeichnis zur Speicherung von temporären Dateien geleert.

Für die Integrationstests ist hier wesentlich mehr Aufwand notwendig, da eine Magento-Sandbox auf Basis der aktuellen Shopkonfiguration sowie eine Testdatenbank erstellt werden muss. Außerdem erweitert Magento PHPUnit um zusätzliche Profiling-Möglichkeiten und einige Observer, die das Schreiben von Tests für den Entwickler erheblich vereinfachen. So stehen dem Entwickler über die durch die Testsuite zusätzlich bereitgestellten Annotations:

  • @magentoAppIsolation
  • @magentoDataFixture
  • @magentoConfigFixture

Funktionen zum automatisierten Anlegen von Test- und Konfigurationsdaten sowie zur Ausführung eines einzelnen Tests in einer isolierten (zurückgesetzten) Instanz zur Verfügung.

Testen in der Sandbox

Die Testsuite erzeugt vor dem Ausführen der Tests eine Sandbox. Hierzu werden alle globalen sowie die in den Extensions enthaltenen Konfigurationsdateien in ein temporäres Sandbox-Verzeichnis unterhalb der jeweiligen Testsuite kopiert. Auf Basis der dort erstellten Verzeichnisstruktur wird der Shop während des Bootstrappings initialisiert. Da für die Tests Anpassungen an den Konfigurationsdateien notwendig sind, stellt dieses Verfahren sicher, dass für die Ausführung der Tests keinerlei Veränderungen am Shop vorgenommen und diese vollkommen isoliert und ohne Nebeneffekte vom Livesystem ausgeführt werden.

Local vs. Distribution Testing

Während der Einführungsphase hat sich gezeigt, dass es aus Zeitgründen in der Praxis nicht möglich ist, bei jedem lokalen Build alle Tests laufen zu lassen. Auf einem gut ausgestatteten Entwicklungsrechner dauert der Durchlauf der gesamten Testsuite einschließlich des Code-Coverage-Reports bereits über 15 Minuten. Hinzu kommen noch die Tests der jeweiligen Extension. Für die lokale Entwicklung und für die Erstellung einer neuen Paketversion steht neben der Standardkonfigurationsdatei phpunit.xml.dist, die alle Tests ausführt (Distribution Testing) noch eine Konfigurationsdatei phpunit.xml.local zur Verfügung, die nur die Tests im Namespace der aktuellen Extension ausführt (Local Testing). Heißt die Extension z. B. TechDivision_GermanTax, so werden beim Aufruf der Tests unter Verwendung der Konfigurationsdatei phpunit.xml.local alle Tests unterhalb des Verzeichnisses dev | tests | integration | testsuite | TechDivision durchlaufen und der Code-Coverage-Report ausschließlich für alle Dateien der jeweiligen Extension erstellt, was, abhängig von der Anzahl der Tests, zu einer erheblichen Zeiteinsparung führt.

Schritt 3: Integration in den Entwicklungsprozess

Mit die größte Herausforderung der Portierung war der dritte und somit letzte Schritt: Die Integration in den Entwicklungsprozess. Mit Magento 2 werden die Testsuite und die Tests standardmäßig ausgeliefert. Die Sourcen von Magento 1 hingegen kommen natürlich ohne Testsuite. Um eine möglichst nahtlose und einfache Integration zu gewährleisten, wurden zur lokalen Entwicklung eingesetzte Magento-Pakete um die Testsuite erweitert. So können 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 Testfälle, also Unit und/oder Integrationstests, ausgeführt werden sollen. Zusätzlich besteht die Möglichkeit, über Build Properties zu definieren, ob nur die jeweiligen Tests der aktuell zu entwickelnden Extension oder zusätzlich auch die Core-Tests ausgeführt werden sollen.

Für den Build- und Deployment-Prozess können Tools wie Phing oder, wie in unserem Fall, ANT verwendet werden. Zum Ausführen der Test stehen die folgend aufgeführten Targets zur Verfügung:

phpunit-run-all-tests phpunit-run-unit-tests phpunit-run-integration-tests

Das ANT Target phpunit-run-integration-tests startet, wie der Name schon sagt, die Integrationstests der Testsuite. In der aktuellen Version werden derzeit 1950 Tests ausgeführt, wobei davon, wie bereits zuvor beschrieben, wegen Inkompatibilitäten mit Magento 1 noch 628 geskippt werden und 27 incomplete sind. Die aktuelle Testsuite mit 2 990 Assertions deckt ca. 11 Prozent der Magento-Core-Klassen ab, sprich noch knapp 90 Prozent des Magento-Quelltexts sind nicht durch Tests abgedeckt.

Diese Targets können entweder direkt aus der lokalen Entwicklungsumgebung oder automatisch während des Builds durch den CI-Server ausgeführt werden. Über die Build Properties kann konfiguriert werden, ob und welche (Distribution- oder Local-)Tests während des Builds ausgeführt werden sollen:

phpunit.tests.execute = false phpunit.database = ${mysql.database}_tests phpunit.testsuite = dist

Zusätzlich kann konfiguriert werden, welche Datenbank für die Ausführung der Integrationstests verwendet werden soll, standardmäßig wird eine zusätzliche leere Datenbank erzeugt. Abbildung 2 zeigt die Ausgabe der Kommandozeile nach dem Durchlauf der Integrationstests der aktuellen Version der Testsuite.

Abb. 2: Integrationstests auf Kommandozeile starten

Laufen die Tests ohne Fehler durch, wird das Paket erstellt und automatisch im PEAR Channel hinterlegt. Selbstverständlich muss nicht zwingend PEAR für das Paketmanagement verwendet werden, PEAR hat sich allerdings 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 im Rahmen eines Projekts lauffähig ist, wird pro Extension und zusätzlich 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 Extension-spezifische Testsuite ausgeführt und nach erfolgreichem Durchlauf ein neues PEAR-Paket mit der aktuellsten Version gebaut und auf dem Channel-Server zur Verfügung gestellt. Vor dem Release eines Projekts werden alle Extensions in der aktuellsten Version installiert und alle Tests – Core und Extension – ausgeführt. Erst, wenn alle Tests über ein Projekt erfolgreich durchlaufen, wird das neue Release zum Deployment freigegeben.

Über das Jenkins Frontend (Abb. 3) haben Scrum Master und Product Owner bereits während des Sprints die Möglichkeit, die verschiedenen Metriken sowie die Anzahl der erstellten Unit und Integrationstests im Auge zu behalten. Nach Abschluss des Sprints gewährleisten die Tests, dass auch bei der Weiterentwicklung der Extension oder des Shops die Qualität einfach und effektiv sichergestellt werden kann.

Abb. 3: Jenkins Frontend

Anlegen von Testdaten

PHPUnit bietet bereits standardmäßig über so genannte Data Providers [4] die Möglichkeit, einen Test mit unterschiedlichen Datenstrukturen auszuführen. Hierzu kann über die Annotation @dataProvider eine Methode deklariert werden, die ein Array oder einen Iterator mit den zu testenden Daten zurückgibt. Die Signatur der zu testenden Methode muss dann analog Listing 1 abhängig von der Datenstruktur die entsprechenden Parameter enthalten.

Listing 1: Data Provider per Annotation
/** * @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') ); }

Speziell für das Ausführen der Integrationstests sind jedoch fast immer Testdaten notwendig, die sich nicht einfach über eine CSV-Datei oder ein Array darstellen lassen. Wie bereits zuvor erwähnt, stellt die Testsuite hierfür über die zusätzlichen Annotations auf Methodenebene

  • @magentoDataFixture
  • @magentoConfigFixture

Funktionen zur Verfügung, mit denen die für den jeweiligen Test erforderlichen Daten bequem angelegt und nach dem Test automatisch wieder gelöscht werden. Somit ist sichergestellt, dass die Datenbank vor jedem Test in ihren Ausgangszustand zurückversetzt wird. Um dies so effizient wie möglich zu gestalten, werden die über die jeweilige Annotation spezifizierten Daten im Rahmen einer Transaktion angelegt, dann der Test ausgeführt und die Transaktion mit einem Rollback zurückgesetzt. Die Datenbank wird somit zu keinem Zeitpunkt verändert, da tatsächlich nie ein Commit für die Transaktion erfolgt.

Für die Annotation @magentoDataFixture muss, wie folgend gezeigt, ein relativer Pfad zur Datei ausgehend vom Basisverzeichnis der jeweiligen Testsuite angegeben werden, z. B.:

/** * @magentoDataFixture Mage/Catalog/_files/product_simple.php */ public function testSomething() { ... }

Innerhalb dieser Skripte kann die Anlage von Testdaten analog der Implementierung innerhalb eines Models vorgenommen werden:

$product = new Mage_Catalog_Model_Product(); $product->setTypeId(Mage_Catalog_Model_Product_Type::TYPE_SIMPLE) ->setId(1) ->setAttributeSetId(4) ... ->save();
Probleme beim Einsatz der Testsuite

Beim Einsatz der Testsuite im täglichen Entwicklungsprozess hat sich eine Vielzahl von Problemen gezeigt, die ohne deren Einsatz nicht auffallen würden. Während der Überarbeitung stellte sich heraus, dass sich die Entwickler der Testsuite auf jeden Fall bis zum Zeitpunkt der Portierung noch nicht mit allen Aspekten des Testens auseinandergesetzt hatten. Nachfolgend möchte ich auf die, aus meiner Sicht, größten Probleme bei der Portierung etwas detaillierter eingehen.

Aufteilung von Installations- und Datenskripten

So werden z. B. häufig die Installations- und Datenskripte nicht entsprechend den von Magento gemachten Vorgaben – Installationsskripte im Verzeichnis sql, Datenskripte im Verzeichnis data – getrennt abgelegt. Erfolgt keine Trennung, kommt es bei Erstellung der Testdatenbank durch die Testsuite zu Fehlern, da Magento im ersten Schritt nur die Tabellen anlegt und keine Daten einspielt. So treten z. B. bei Installation einer Extension ohne diese Trennung, bei der Verknüpfungen der Daten zur Steuertabelle angelegt werden sollen, zwangsläufig Constraint-Probleme auf, da die Steuerdaten zu diesem Zeitpunkt eben aufgrund der Trennung noch nicht existieren.

Die Trennung in Installations- und Datenskripte allein trägt zwar an sich bereits zur Vermeidung von Problemen bei, reicht jedoch noch nicht aus. Zusätzlich ist es zwingend erforderlich, in der entsprechenden Konfigurationsdatei unter app | etc | modules Abhängigkeiten zu anderen Extensions (auch zu Core-Modulen) zu hinterlegen. Anhand dieser Abhängigkeiten wird bei der Installation der Testdatenbank durch die Testsuite die Reihenfolge, in der die Installations- und Datenskripte ausgeführt werden, festgelegt. Nur so kann sichergestellt werden, dass eine benötigte Tabelle oder deren Daten vor dem Ausführen des Installations- oder Datenskripts auch tatsächlich vorhanden sind.

Lokalisierungen

Ein weiteres Problem ergibt sich aufgrund der Lokalisierung von Projekten. Die von Magento erstellte Testsuite für Magento 2 geht davon aus, dass die Testdatenbank für die USA lokalisiert ist. So wird in diversen Tests auf fest hinterlegte Werte wie z. B. auf Preise in USD geprüft:

$this->assertEquals('$10.00', $this->_model->getFormatedPrice());

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 lösen, müssen die fest hinterlegten Werte entsprechend der im jeweiligen Shop konfigurierten Local lokalisiert und erst dann geprüft werden:

$formattedPrice = Mage::app()->getStore()->formatPrice(0.00, false); $this->assertEquals('' . $formattedPrice . '', $this->_model->getFormatedPrice());

Integration von Drittanbieter-Extensions

Im Laufe der Einführung hat sich neben Abhängigkeiten von Extensions auch gezeigt, dass die Magento-Core-Tests bei der Integration von Drittanbieter-Extensions in vielen Fällen fehlschlagen. Dies beruht auf dem Umstand, dass die Extensions durch das Überschreiben von Core-Klassen die ursprüngliche Funktionalität verändern. Grundsätzlich lässt sich dieses Problem auf drei Arten lösen:

Die erste und beste Möglichkeit ist natürlich der gänzliche Verzicht auf Rewrites, das Problem stellt sich somit gar nicht erst.

Die zweite Möglichkeit, die immer dann verwendet werden sollte, wenn die Verwendung eines Rewrites unumgänglich ist, erlaubt dem Entwickler, die Extension per Konfiguration über die Systemsteuerung zu aktivieren. Die Core-Tests schlagen somit nicht fehl, da die Extension zuerst über die Annotation @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 die Methode des gezeigten DocBlocks z. B. den Core-Test MageTest::testGetModel() ersetzen:

/** * @magentoRewriteTestMethod MageTest::testGetModel() */ public function testGetModel() { ... }
Abhängigkeiten von Extensions

Lokalisierung und Drittanbieter-Extensions stellen sicherlich nicht zu unterschätzende Probleme dar, die jedoch relativ leicht in den Griff zu bekommen sind. Als deutlich komplizierteres Problem hat sich die Abhängigkeit von Extensions beim Ausführen der Testsuite gezeigt.

Abhängigkeiten zum Magento Core spielen natürlich nur eine untergeordnete Rolle (siehe Aufteilung von Installations- und Datenskripten). Hat eine Extension jedoch eine oder gar mehrere Abhängigkeiten zu anderen oder Drittanbieter-Extensions, so müssen diese beim Aufruf der Testsuite ebenfalls vorhanden sein. Magento hat zwar einen Mechanismus, einer Extension mitzuteilen, dass diese von einer oder mehreren anderen abhängig ist, allerdings werden bei der Installation abhängige Extensions nicht automatisch mitinstalliert. Die Lösung dieses Problems ist in diesem Fall abhängig vom eingesetzten Build-Tool und vom Paketmanagement, in unserem Fall also ANT und PEAR [5]. Für jedes PEAR-Paket lassen sich Abhängigkeiten definieren, die bei der Installation sicherstellen, dass benötigte Pakete auf jeden Fall vorhanden sind.

Beim Aufruf eines der ANT Targets (siehe „Schritt 3: Integration in den Entwicklungsprozess“) zum Ausführen der Testsuite wird, falls nicht bereits vorhanden, automatisiert eine neue Magento-Instanz angelegt und ein für jede Instanz separater PEAR Channel initialisiert. Anschließend wird lokal ein PEAR-Paket aus der aktuellsten Version der Sourcen erzeugt und über den zuvor initialisierten PEAR Channel installiert. Benötigt das Paket andere Pakete, so werden diese über die im PEAR-Paket definierten Abhängigkeiten ebenfalls mitinstalliert. Somit wird vor dem Aufruf der Testsuite eine konsistente Testumgebung aufgebaut, die sicherstellt, dass alle zur Ausführung der Tests benötigten 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 Deployment-Prozess integrieren. Die Antwort darauf lautet, dass in vielen Projekten aus Effizienz- und Kostengründen Drittanbieter-Extensions verwendet werden, deren Funktionalität jedoch fast immer erweitert werden muss. In den meisten Fällen wird hierzu eine weitere abhängige Extension implementiert, um bei einem Update der Extension Probleme zu vermeiden. Wie zuvor beschrieben, ist es für den Einsatz der Testsuite notwendig, die Drittanbieter-Extension ebenfalls zu installieren, genau das lässt sich jedoch nur erreichen, wenn diese auch in den eigenen Build- und Deployment-Prozess integriert ist.

Fazit

Trotz der aktuell noch relativ geringen Testabdeckung, hat bereits die Einführung der Testsuite zu einer erheblichen Verbesserung der Qualität beigetragen. So konnten schon während der Migration zahlreiche im herkömmlichen Betrieb nicht sichtbare Probleme erkannt und beseitigt werden. Durch die Einführung und die tägliche 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 zusätzliche Aufwände in Form von Einarbeitung, Workshops und dem Schreiben von Tests, jedoch zeigt sich bereits nach kurzer Zeit, dass die Qualität und damit auch die Kundenzufriedenheit proportional zu den Aufwänden steigt.

Der aktuelle Stand der Testsuite kann über das GitHub Repository [6] der TechDivision GmbH heruntergeladen und kostenfrei in eigenen Projekten eingesetzt werden. Da aus Kompatibilitätsgründen derzeit noch zahlreiche Tests deaktiviert wurden, freuen wir uns natürlich über Unterstützung aus der Community, um alle sinnvollen Tests aus Magento 2 zu portieren und eine möglichst große Testabdeckung zu erreichen.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -