ApiTestCase Download - ApiTestCase Quellcode-Download

ApiTestCase

Python

v5.3.4

Herunterladen

ApiTestCase

ApiTestCase ist ein PHPUnit-TestCase, der Ihnen das Leben als Symfony-API-Entwickler erheblich erleichtern wird. Es erweitert das grundlegende Symfony WebTestCase um einige coole Funktionen.

Dank PHP-Matcher können Sie laut Readme „erwartete JSON-Antworten wie ein Gangster schreiben“. Wir sind uns auf jeden Fall einig.

Außerdem wird Alice zum einfachen Laden von Doctrine-Fixtures verwendet.

Merkmale:

Klarer TDD-Workflow für die API-Entwicklung mit Symfony;
JSON/XML-Abgleich mit klaren Fehlermeldungen;
Fixtures laden mit Alice (optional) ;

Installation

Vorausgesetzt, Sie haben Composer bereits global installiert:

composer require --dev lchrusciel/api-test-case

Und es ist geschafft! ApiTestCase arbeitet mit der Standardkonfiguration.

Verwendung

Wir stellen zwei Basisklassen für Ihre Testfälle bereit: JsonApiTestCase und XmlApiTestCase. Wählen Sie eines basierend auf dem Format der API aus, die Sie erstellen möchten.

Json-Beispiel

Der grundlegende TDD-Workflow ist der folgende:

Schreiben Sie einen Testfall, der die Anfrage sendet, und verwenden Sie die Assertionsmethode assertResponse , um zu überprüfen, ob der Antwortinhalt Ihren Erwartungen entspricht. Sie benötigen einen Namen für die Antwortdatei;
Erstellen Sie die Datei mit dem Namen, den Sie in Schritt 1 ausgewählt haben, und fügen Sie dort den erwarteten Antwortinhalt ein. Es sollte beispielsweise in src/AppBundle/Tests/Responses/Expected/hello_world.json abgelegt werden.
Mach es rot.
Mach es grün.
Umgestalten.

Sehen wir uns ein einfaches Beispiel an! Schreiben Sie den folgenden Test:

 namespace AppBundle  Tests  Controller  HelloWorldTest ;

use ApiTestCase  JsonApiTestCase ;

class HelloWorldTest extends JsonApiTestCase
{
    public function testGetHelloWorldResponse ()
    {
        $ this -> client -> request ( ' GET ' , ' / ' );

        $ response = $ this -> client -> getResponse ();

        $ this -> assertResponse ( $ response , ' hello_world ' );
    }
}

Definieren Sie nun die erwartete Antwortdatei:

{
    "message" : " Hello ApiTestCase World! "
}

Führen Sie Ihre Tests durch:

vendor/bin/phpunit

Ihr Test sollte mit einigen Fehlern fehlschlagen. Wahrscheinlich fehlen Ihnen der Controller und das Routing. Definieren Sie sie also! Sobald Sie Ihren Controller implementiert und das entsprechende Routing konfiguriert haben, können Sie Ihre Tests erneut ausführen:

Wenn der Inhalt der Antwort unseren Erwartungen entspricht, zeigt die Konsole eine einfache Meldung an:

OK (1 tests, 2 assertions)

Andernfalls werden die Unterschiede der empfangenen Nachrichten angezeigt:

 " Hello ApiTestCase World " does not match " Hello ApiTestCase World! " .
@@ -1,4 +1,3 @@
 {
-    " message " : " Hello ApiTestCase World! "
+    " message " : " Hello ApiTestCase World "
 }
-

Zuerst prüft die Funktion assertResponse den Antwortcode (200 ist ein Standardantwortcode) und prüft dann, ob der Header der Antwort den Inhaltstyp application/json enthält. Am Ende wird geprüft, ob der Inhalt der Antwort den Erwartungen entspricht. Manchmal können Sie einige Werte in der Antwort nicht vorhersagen, beispielsweise das automatisch generierte Datum oder die ID aus der Datenbank. Hier ist keine Zauberei nötig, denn PHP-Matcher kommt mit einer helfenden Hand. Dies sind nur einige Beispiele verfügbarer Muster:

@string@
@integer@
@boolean@
@array@

Weitere Informationen finden Sie in der Dokumentation von PHP-Matcher.

Mit diesen Mustern sieht Ihre erwartete Reaktion folgendermaßen aus:

{
    "message" : " @string@ "
}

Wenn dies eingerichtet ist, stimmt jede Zeichenfolge unter der message mit dem Muster überein. Eine kompliziertere erwartete Antwort könnte so aussehen:

[
    {
        "id" : " @integer@ " ,
        "name" : " Star-Wars T-shirt " ,
        "sku" : " SWTS " ,
        "price" : 5500 ,
        "sizes" : " @array@ " ,
        "created_at" : " @[email protected]() "
    },
    {
        "id" : " @integer@ " ,
        "name" : " Han Solo Mug " ,
        "sku" : " HSM " ,
        "price" : 500 ,
        "sizes" : " @array@ " ,
        "created_at" : " @[email protected]() "
    }
]

Und passt zu der folgenden Produktliste:

 array (
    array (
        ' id ' => 1 ,
        ' name ' => ' Star-Wars T-shirt ' ,
        ' sku ' => ' SWTS ' ,
        ' price ' => 5500 ,
        ' sizes ' => array ( ' S ' , ' M ' , ' L ' ),
        ' created_at ' => new  DateTime (),
    ),
    array (
        ' id ' => 2 ,
        ' name ' => ' Han Solo Mug ' ,
        ' sku ' => ' HSM ' ,
        ' price ' => 500 ,
        ' sizes ' => array ( ' S ' , ' L ' ),
        ' created_at ' => new  DateTime (),
    ),
)

Testen mit Datenbank-Fixtures

ApiTestCase ist in nelmio/alice integriert. Dank dieser schönen Bibliothek können Sie Ihre Fixtures ganz einfach laden, wenn Sie sie brauchen. Sie müssen Ihre Geräte definieren und in einem geeigneten Verzeichnis ablegen. Hier finden Sie einige Beispiele für die Definition Ihrer Geräte und Anwendungsfälle. Weitere Informationen zum Definieren Ihrer Geräte finden Sie in der Dokumentation von Alice.

Um Alice mit Doctrine nutzen zu können, sollten Sie zwei zusätzliche Bundles aktivieren:

Symfony 4.0+

 // config/bundles.php
return [
    // ...
    
    Nelmio  Alice  Bridge  Symfony NelmioAliceBundle::class => [ ' test ' => true ],
    Fidry  AliceDataFixtures  Bridge  Symfony FidryAliceDataFixturesBundle::class => [ ' test ' => true ],
];

Angenommen, Sie haben in Ihrer Anwendung eine zugeordnete Doctrine-Entität namens „Book“:

    class Book 
    {
        private $ id ;
        private $ title ;
        private $ author ;
    
        // ... 
    }

Um Fixtures für den Test zu laden, müssen Sie eine einfache YAML Datei in src/AppBundle/Tests/DataFixtures/ORM/books.yml definieren:

    ApiTestCaseTestEntityBook :
        book1 :
            title : " Lord of The Rings "
            author : " J. R. R. Tolkien "
        book2 :
            title : " Game of Thrones "
            price : " George R. R. Martin "

Um diese Fixtures schließlich in einem Test zu verwenden, rufen Sie einfach eine geeignete Methode auf:

    public function testBooksIndexAction ()
    {
        // This method require subpath to locate specific fixture file in your DataFixtures/ORM directory.
        $ this -> loadFixturesFromFile ( ' books.yml ' );  
      
        // There is another method that allows you to load fixtures from directory.
        $ this -> loadFixturesFromDirectory ( ' big_library ' );
    }

Konfigurationsreferenz

Um Ihre Testsuite-Konfiguration anzupassen, können Sie phpunit.xml einige weitere Optionen hinzufügen:

< php >
    < server name = " KERNEL_CLASS " value = " AcmeKernel " />
    < server name = " EXPECTED_RESPONSE_DIR " value = " /path/to/expected/responses/ " />
    < server name = " FIXTURES_DIR " value = " /path/to/DataFixtures/ORM/ " />
    < server name = " OPEN_ERROR_IN_BROWSER " value = " true/false " />
    < server name = " OPEN_BROWSER_COMMAND " value = " open %s " />
    < server name = " IS_DOCTRINE_ORM_SUPPORTED " value = " true/false " />
    < server name = " TMP_DIR " value = " /tmp/path/to/temporary/folder/ " />
    < server name = " ESCAPE_JSON " value = " true/false " />
</ php >

KERNEL_CLASS können Sie genau angeben, welche Klasse zum Einrichten des Kernels verwendet werden soll.
Die Variable ERESPONSE_DIR enthält Pfade zu Ordnern mit erwarteten Antworten. Es wird verwendet, wenn das API-Ergebnis mit einer vorhandenen JSON-Datei verglichen wird. Wenn dieser Wert nicht festgelegt ist, versucht ApiTestCase, den Speicherort der Antworten zu erraten und sucht nach den Antworten in einem Ordner: „../Responses“, der sich relativ zu Ihrer Controller-Testklasse befindet.
Die Variable FIXTURES_DIR enthält einen Pfad zum Ordner mit Ihren Datengeräten. Wenn diese Variable nicht gesetzt ist, wird standardmäßig nach ../DataFixtures/ORM/ gesucht, das sich relativ zu Ihrer Testklasse befindet. ApiTestCase löst eine RunTimeException aus, wenn der Ordner nicht vorhanden ist oder keine Dateien geladen werden können.
OPEN_ERROR_IN_BROWSER ist ein Flag, das die Anzeige von Fehlern in einem Browserfenster aktiviert. Der Standardwert ist false.
OPEN_BROWSER_COMMAND ist ein Befehl, der zum Öffnen des Browsers mit einer Ausnahme verwendet wird.
IS_DOCTRINE_ORM_SUPPORTED ist ein Flag, das die Doctrine-Unterstützung aktiviert und einen praktischen Daten-Fixture-Loader und einen Datenbank-Purger umfasst.
Die Variable TMP_DIR enthält einen Pfad zum temporären Ordner, in dem die Protokolldateien gespeichert werden.
ESCAPE_JSON ist ein Flag, das das Escapezeichen (Unicode-Zeichen und Schrägstriche) Ihrer JSON-Ausgabe aktiviert, bevor sie mit erwarteten Daten verglichen wird. Der Standardwert ist false. Dieses Flag existiert nur aus Gründen der Abwärtskompatibilität mit früheren Versionen von ApiTestCase (wenn aktiviert) und wird in einer zukünftigen Version entfernt.

Beispielprojekt

Im Verzeichnis test/ finden Sie ein Symfony-Beispielprojekt mit minimaler Konfiguration, die für die Verwendung dieser Bibliothek erforderlich ist.

Testen

Um unsere PHPUnit-Testsuite auszuführen, führen Sie die folgenden Befehle aus:

composer install
test/app/console doctrine:database:create
test/app/console doctrine:schema:create
vendor/bin/phpunit

Fehlerverfolgung und Vorschläge

Wenn Sie einen Fehler gefunden haben oder eine tolle Verbesserungsidee haben, öffnen Sie bitte ein Problem in diesem Repository.

Versionierung

Veröffentlichungen werden im Format major.minor.patch nummeriert.

Und nach den folgenden Richtlinien konstruiert.

Die Aufhebung der Abwärtskompatibilität bringt den Großteil ins Wanken.
Neue Ergänzungen ohne Beeinträchtigung der Abwärtskompatibilität beeinträchtigen den Minderjährigen.
Fehlerbehebungen und sonstige Änderungen runden den Patch ab.

Weitere Informationen zu SemVer finden Sie auf der Website semver.org.