Tag: Testing

Gelegentlich funktioniert die Weiterleitung beim One Page Checkout nicht mehr, nachdem irgendein neues Modul Debug-Ausgaben macht oder Fehler wirft. Exceptions beim Versand der Bestätigungs-Mail sind auch eine häufige Ursache.
Das ist ein ziemlich gravierender Fehler, der aber leicht unbemerkt bleibt. Nachdem ich das nun ein paar Mal hatte, war klar: Der Checkout muss beim Regressionstest automatisch getestet werden, so dass ich über so einen Fehler rechtzeitig informiert werde. Alistair Steads hat glücklicherweise beispielhaft einen Checkout Integration Test online gestellt, seine Bibliothek Mage-Test benutze ich allerdings nicht mehr, habe den Test also für EcomDev PHPUnit 0.2 umgeschrieben. Am Code der Test-Methode ändert sich zunächst nicht viel, nur ein paar Methoden heißen anders. Das Setup ist allerdings mal wieder etwas kniffelig, daher will ich es hier mal etwas näher beleuchten. Links zum fertigen Test Case folgen unten.

Zunächst mal wird mindestens ein Produkt für den Warenkorb benötigt, die Unit Tests laufen ja auf ihrer eigenen Datenbank, die für jeden Test mittels Fixtures entsprechend vorbereitet werden muss (mehr dazu im EcomDev PHPUnit Manual). Hier die Minimal-Daten für unsere Zwecke:

eav:
  catalog_product:
    -
      entity_id: 1
      stock:
        qty: 100
        is_in_stock: 1
      website_ids:
        - default
      sku: test
      name: Test
      status: 1 # enabled
      type_id: simple
      price: 1.00

Um sicherzustellen, dass die Bestellung akzeptiert wird, sollte das Empfängerland explizit erlaubt sein und die Funktion “Terms & Conditions” deaktiviert werden:

config:
  default/general/country/allow: DE,GB
  stores/default/checkout/options/enable_agreements: 0

Außerdem muss die Zahlungsmethode konfiguriert sein. Ich habe mich dazu entschieden, für den Test “Scheck / Zahlungsanweisung” statt Paypal zu verwenden, die Standard-Methode, die keine Konfiguration benötigt. Wenn explizit verschiedene Zahlungsmethoden getestet werden sollen, ist ein aufwändigeres Setup nötig, das macht meiner Meinung nach in der isolierten Testumgebung aber wenig Sinn.

Ganz wichtig ist, dass nachdem der Warenkorb gefüllt wurde, der Session-Wert cart_was_updated auf false gesetzt wird, ansonsten bricht der Test mit einer wenig aussagekräftigen “Headers already sent”-Exception ab (mehr dazu unten).

    protected function _fixCheckout()
    {
        Mage::getSingleton('checkout/session')->setCartWasUpdated(false);
    }

Eine weitere Überraschung gab es, nachdem der Test das erste Mal erfolgreich durchlief und beim nächsten Mal ohne ersichtlichen Grund einen Fehler in der JSON-Ausgabe meldete. Gut, wenn man Exception-Logging aktiviert hat: Grund war eine PDOException aufgrund doppeltem Schlüssel in der Order-Tabelle. Das interessante: Das EcomDev Test-Framework räumt die Datenbank eigentlich nach jedem Testlauf ab (wenn nicht gerade ein Fatal Error der Ausführung der tearDown-Methoden zuvorkommt) aber für die beim Checkout generierte Bestellung (und nur die) funktionierte das nicht. Als Ursache vermute ich die zusätzliche Kontrolle im Order-Model, die verhindern soll, dass Bestellungen von irgendeinem Modul außerhalb des Admin-Bereichs gelöscht werden können. Jedenfalls hat das setzen des isSecureArea-Flags geholfen, generierte Bestellungen wieder zu löschen:

    /**
     * Deletes any created order
     * 
     * @return void
     */
    protected function _deleteOrders()
    {
        Mage::register('isSecureArea', true);
        /* @var $orders Mage_Sales_Model_Mysql4_Order_Collection */
        $orders = Mage::getModel('sales/order')->getCollection()->load();
        $orders->walk('delete');
    }

Dinge, die ich beim Debuggen gelernt habe

1. Der One Page Checkout Controller reagiert auf diverse Fehler mit einem 403 Session Expired Header, was gemeinerweise vom Test-Framework nur mit einer “Headers already sent”-Exception beim verarbeiten des Response-Objekts quittiert wird. Den Fehler habe ich natürlich erst bei mir selbst gesucht, aber das Response-Objekt wurde überall sauber resettet.
   Zu den verursachenden Fehlern dieses Headers gehören ein leerer Warenkorb und jegliche Fehler aus dem Quote-Model (siehe dazu die Methode OnepageController::­_expireAjax()). Um so etwas zu finden, empfiehlt es sich, die Header direkt an der Stelle, wo die Exception geworfen wird zu analysieren und dann im Magento-Source nach dem Header-Text zu suchen.
2. Um aufzudecken, welche Exceptions zu (oft wenig hilfreichen) Magento-Fehlermeldungen geführt haben, ist das Exception-Log bei Integrationstests unentbehrlich. Die Fixture dazu sieht so aus:

    stores/default/dev/log/active: 1
     stores/default/dev/log/file: tests-system.log
     stores/default/dev/log/exception_file: tests-exception.log
   

Quelltext

Wie versprochen, stehen Fixture & Test Case als github:gist online zur Verfügung.