Integrationen testen #

Diese Seite richtet sich an Entwickler und Tester von Integrationen. Eine Integration hat zwei Systeme, ein Netzwerk und Daten, die sich unter ihr ändern; die meisten ihrer Fehler lassen sich mit ein paar Arten von Tests vor dem Go-live finden. Die Mechanik auf Seiten der Erweiterung steht unter Tests für Erweiterungen.

Inhalt #

1. Die Testpyramide einer Integration
2. Unit-Tests ohne Datenbank
3. Das andere System als Test-Double
4. Tests mit geladenem Kernel
5. Probeläufe und der Idempotenztest
6. Mail, Webhooks und Sandboxes
7. Abnahme mit dem Kunden

Die Testpyramide einer Integration #

Unit-Tests ohne Datenbank #

Halten Sie die Logik, die keinen Kernel braucht, in einfachen Klassen: den CSV-Parser, die Zuordnung einer Quellzeile zu Attributwerten, den Aufbau der Nutzlast, die Signaturprüfung. Sie laufen in Millisekunden mit dem PHPUnit aus dem vendor/ des Kernels:

<?php
use PHPUnit\Framework\TestCase;

final class ProductMappingTest extends TestCase
{
    public function testPriceIsWrittenInThePriceDatatypeFormat(): void
    {
        $mapping = new myIntegrationProductMapping();
        $attributes = $mapping->attributes( array( 'ARTNR' => '10442', 'NAME' => ' Trail shoe ', 'PRICE' => '119.00', 'STOCK' => '7' ) );
        $this->assertSame( '119.00|1|1', $attributes['price'] );
        $this->assertSame( 'Trail shoe', $attributes['name'] );
    }

    public function testRowsWithoutAnArticleNumberAreRefused(): void
    {
        $this->assertNull( ( new myIntegrationProductMapping() )->attributes( array( 'ARTNR' => '', 'PRICE' => '1' ) ) );
    }
}

Führen Sie sie aus dem Verzeichnis der Erweiterung mit php ../../vendor/bin/phpunit und einer phpunit.xml.dist wie im oben genannten Kapitel aus (PHPUnit-Tests ohne Datenbank).

Das andere System als Test-Double #

Legen Sie das andere System hinter eine eigene Schnittstelle (myIntegrationHubClient mit send()), und geben Sie Tests eine Attrappe, die Aufrufe aufzeichnet und beantwortet, was der Test braucht: Erfolg, 429 mit Retry-After, 500, ein Timeout, einen ungültigen Inhalt. Testen Sie dann, dass Ihr Sender Zeilen nur bei Erfolg als gesendet markiert, bei 429 zurückweicht und eine Zeile nach dem letzten Versuch in die Dead-Letter-Ablage verschiebt. Bewahren Sie einige aufgezeichnete echte Antworten des anderen Systems als Fixtures auf und aktualisieren Sie sie, wenn sich dessen API ändert.

Tests mit geladenem Kernel #

Ein Testskript, das mit php bin/php/ezexec.php <script> -s <siteaccess> auf einer Entwicklungsinstallation läuft, kann Objekte mit einem Testpräfix anlegen, prüfen und wieder entfernen:

<?php
// extension/myintegration/tests/scripts/upsert_check.php, run with bin/php/ezexec.php on a development copy only
$importer = new myIntegrationProductImport( $cli, false );
$remoteID = 'test-erp-product-' . time();
// ... call the upsert with a test record, then:
$object = eZContentObject::fetchByRemoteID( $remoteID );
$cli->output( $object instanceof eZContentObject ? 'PASS created' : 'FAIL not created' );
if ( $object instanceof eZContentObject )
{
    $object->removeThis();   // or remove its node to the trash; development copies only
}

ezexec.php aktiviert die Testklassen im Verzeichnis tests/ einer Erweiterung für ein Skript darin. Führen Sie solche Skripte nie gegen die Produktion aus.

Probeläufe und der Idempotenztest #

1. Kopieren Sie die Produktion (Datenbank und var/storage) auf eine Testinstallation; anonymisieren Sie personenbezogene Daten, wenn die Kopie die Produktionsumgebung verlässt.
2. Führen Sie den Import mit --dry-run aus: Die Zahlen müssen plausibel sein (nicht "20 000 angelegt" auf einer Website, die alle schon hat).
3. Führen Sie ihn wirklich aus; prüfen Sie eine Stichprobe von Objekten.
4. Führen Sie ihn sofort noch einmal aus: Er darf nur unchanged melden. Jedes updated bedeutet, dass die Änderungserkennung Formate vergleicht, die sich unterscheiden.
5. Entfernen Sie einen Datensatz aus der Quelle und führen Sie ihn erneut aus: Die Regel für Entfernungen muss greifen, und der Sicherheitsstopp muss auslösen, wenn die Quelle absichtlich gekürzt wird.

Mail, Webhooks und Sandboxes #

• Mail: site.ini [MailSettings] Transport=file auf jeder Testinstallation, und prüfen Sie, dass settings/override keinen anderen Transport erzwingt; Testadressen auf example.invalid.
• Ausgehende Webhooks: Richten Sie sie auf einen eigenen Empfänger im Testnetzwerk und testen Sie die Signaturprüfung mit einem falschen Geheimnis und einem alten Zeitstempel.
• Zahlungs- und Identitätsanbieter: Verwenden Sie deren Sandboxes; nie echte Karten oder echte Konten.
• API-Schlüssel: eigene Schlüssel für Testinstallationen, mit kurzer Laufzeit.

Abnahme mit dem Kunden #

Schreiben Sie Abnahmefälle in der Sprache des Kunden, mit Daten, die er kennt: "Artikel 10442, um 14:00 im ERP geändert, zeigt bis 14:10 den neuen Preis auf der Produktseite." Lassen Sie sie vor dem Go-live abzeichnen und bewahren Sie sie für das nächste Upgrade auf, wenn sie zum Regressionstest werden (Upgrades ohne defekte Integrationen).

Verwandte Seiten #

• Tests für Erweiterungen
• Anwendungen testen
• Qualitätstore und Abnahme
• Go-live-Checkliste für Integrationen
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.