Die Kopplung von Datenzugriff und dem Domain Modell benötigt oft die Verwendung einer Datenbank für Testzwecke. Aber die Datenbank ist persistent über alle Tests was dazu führen kann das die Test Resultate sich gegenseitig beeinflussen. Weiters ist das Setup der Datenbank eine ganz schöne Arbeit damit die Tests laufen können. PHPUnit's Datenbank Extension vereinfacht das Testen mit einer Datenbank durch das Anbieten eines einfachen Mechanismus für das Setup und Herunterfahren der Datenbank zwischen den unterschiedlichen Tests. Diese Komponente erweitert die PHPUnit Datenbank Extension mit Zend Framework spezifischem Code, damit das Schreiben von Datenbank Tests für Zend Framework Anwendungen vereinfacht wird.
Das Testen von Datenbanken kann mit zwei konzeptionellen Einträgen beschrieben werden,
DataSets und DataTables. Intern kann die PHPUnit Datenbank Extension eine Objekt Struktur
von einer Datenbank erstellen, und dessen Tabellen und enthaltene Zeilen von einer
Konfigurationsdatei oder einer realen Datenbankinhalt. Dieser abstrakte Objektgraph kann
dann verglichen werden indem Assertions verwendet werden. Ein üblicher Verwendungszweck
beim Testen von Datenbanken ist das Setup von einigen Tabellen mit eingefügten Daten, in
denen dann einige Operationen stattfinden, und letztendlich geprüft wird das der
endgültige Datenbankstatus identisch mit dem vordefinierten und erwarteten Status ist.
Zend_Test_PHPUnit_Db
vereinfacht diese Aufgabe indem es erlaubt wird
DataSets und DataTables von existierenden Zend_Db_Table_Abstract
oder Zend_Db_Table_Rowset_Abstract
Instanzen erstellt werden.
Weiters erlaubt es diese Komponente jede Zend_Db_Adapter_Abstract
für das Testen zu integrieren wobei die originale Erweiterung nur mit
PDO arbeitet. Eine Implementation des Test Adapters für
Zend_Db_Adapter_Abstract
ist auch in dieser Komponente inkludiert.
Sie erlaubt es einen Db Adapter zu instanziieren der überhaupt keine Datenbank benötigt und
als SQL arbeitet sowie als Ergebnis Stack der von den
API Methoden verwendet wird.
Wir schreiben jetzt einige Datenbank Tests für das Bug Datenbank Beispiel in der
Dokumentation von Zend_Db_Table
. Zuerst beginnen wir zu
Testen ob ein neuer Bug der eingefügt wird, in der Datenbank auch wirklich korrekt
abgespeichert wird. Zuerst müssen wir eine Test-Klasse erstellen die
Zend_Test_PHPUnit_DatabaseTestCase
erweitert. Diese Klasse
erweitert die Datenbank Erweiterung von PHPUnit, welche Ihrerseits den standardmäßigen
Basis PHPUnit_Framework_TestCase
erweitert. Ein Datenbank
Testcase enthält zwei abstrakte Methoden die implementiert werden müssen, eine für die
Datenbank Verbindung und eine für das initiale Datenset das als Seed oder Fixum
verwendet werden soll.
Anmerkung
Man sollte mit der PHPUnit Datenbank Erweiterung vertraut sein um diesem Quickstart einfach folgen zu können. Auch wenn diese Konzepte in dieser Dokumentation beschrieben werden, kann es hilfreich sein zuerst die Dokumentation von PHPUnit zu lesen.
class BugsTest extends Zend_Test_PHPUnit_DatabaseTestCase { private $_connectionMock; /** * Returns the test database connection. * * @return PHPUnit_Extensions_Database_DB_IDatabaseConnection */ protected function getConnection() { if($this->_connectionMock == null) { $connection = Zend_Db::factory(...); $this->_connectionMock = $this->createZendDbConnection( $connection, 'zfunittests' ); Zend_Db_Table_Abstract::setDefaultAdapter($connection); } return $this->_connectionMock; } /** * @return PHPUnit_Extensions_Database_DataSet_IDataSet */ protected function getDataSet() { return $this->createFlatXmlDataSet( dirname(__FILE__) . '/_files/bugsSeed.xml' ); } }
Hier erstellen wir die Datenbankverbindung und setzt einige Daten in die Datenbank. Einige wichtige Details über diesen Code sollten notiert werden:
-
Man kann ein
Zend_Db_Adapter_Abstract
nicht direkt von dergetConnection()
Methode erhalten, aber einen PHPUnit spezifischen Wrapper welcher mit der MethodecreateZendDbConnection()
erstellt wird. -
Das Datenbank Schema (Tabellen und Datenbank) wird nicht bei jedem Testlauf wieder erstellt. Die Datenbank und die Tabellen müssen manuell erstellt werden bevor die Tests aufgeführt werden.
-
Datenbank Tests schneiden standardmäßig die Daten während
setUp()
ab und fügen anschließend die Seed Daten ein, welche von der MethodegetDataSet()
zurückgegeben werden. -
DataSets müssen das Interface
PHPUnit_Extensions_Database_DataSet_IDataSet
implementieren. Es gibt eine Vielzahl an Typen von XML und YAML Konfigurationsdateien die in PHPUnit enthalten sind, welche es erlauben zu spezifizieren wie Tabellen und Datensätze auszusehen haben und man sollte in die Dokumentation von PHPUnit schauen um die aktuellsten Informationen über die Spezifikation diese Datensets zu erhalten.
Im vorhergehenden Setup für den Datenbank Testcase haben wir eine Seed Datei für das Datenbank Fixum spezifiziert. Jetzt erstellen wir diese Datei im spezifizierten Flat XML Format:
<?xml version="1.0" encoding="UTF-8" ?> <dataset> <zfbugs bug_id="1" bug_description="system needs electricity to run" bug_status="NEW" created_on="2007-04-01 00:00:00" updated_on="2007-04-01 00:00:00" reported_by="goofy" assigned_to="mmouse" verified_by="dduck" /> <zfbugs bug_id="2" bug_description="Implement Do What I Mean function" bug_status="VERIFIED" created_on="2007-04-02 00:00:00" updated_on="2007-04-02 00:00:00" reported_by="goofy" assigned_to="mmouse" verified_by="dduck" /> <zfbugs bug_id="3" bug_description="Where are my keys?" bug_status="FIXED" created_on="2007-04-03 00:00:00" updated_on="2007-04-03 00:00:00" reported_by="dduck" assigned_to="mmouse" verified_by="dduck" /> <zfbugs bug_id="4" bug_description="Bug no product" bug_status="INCOMPLETE" created_on="2007-04-04 00:00:00" updated_on="2007-04-04 00:00:00" reported_by="mmouse" assigned_to="goofy" verified_by="dduck" /> </dataset>
Wir arbeiten mit diesen vier Einträgen, der Datenbank Tabelle "zfbugs", im nächsten Beispiel. Das benötigte MySQL Schema für dieses Beispiel ist:
CREATE TABLE IF NOT EXISTS `zfbugs` ( `bug_id` int(11) NOT NULL auto_increment, `bug_description` varchar(100) default NULL, `bug_status` varchar(20) default NULL, `created_on` datetime default NULL, `updated_on` datetime default NULL, `reported_by` varchar(100) default NULL, `assigned_to` varchar(100) default NULL, `verified_by` varchar(100) default NULL, PRIMARY KEY (`bug_id`) ) ENGINE=InnoDB AUTO_INCREMENT=1 ;
Jetzt, da wie die zwei benötigten Abstrakten Methoden von
Zend_Test_PHPUnit_DatabaseTestCase
implementiert, und den
Datenbank Inhalt des Seeds spezifiziert haben, der für jeden neuen Test wieder erzeugt
wird, können wir dazu übergehen unsere erste Annahme zu treffen. Das wird ein Test um
einen neuen Fehler einzufügen.
class BugsTest extends Zend_Test_PHPUnit_DatabaseTestCase { public function testBugInsertedIntoDatabase() { $bugsTable = new Bugs(); $data = array( 'created_on' => '2007-03-22 00:00:00', 'updated_on' => '2007-03-22 00:00:00', 'bug_description' => 'Something wrong', 'bug_status' => 'NEW', 'reported_by' => 'garfield', 'verified_by' => 'garfield', 'assigned_to' => 'mmouse', ); $bugsTable->insert($data); $ds = new Zend_Test_PHPUnit_Db_DataSet_QueryDataSet( $this->getConnection() ); $ds->addTable('zfbugs', 'SELECT * FROM zfbugs'); $this->assertDataSetsEqual( $this->createFlatXmlDataSet(dirname(__FILE__) . "/_files/bugsInsertIntoAssertion.xml"), $ds ); } }
Jetzt sieht ab $bugsTable->insert($data);
alles wie gewohnt
aus. Die Zeilen danach enthalten den Assertion Methodennamen. Wir wollen prüfen ob, nach
dem Einfügen des neuen Fehlers, die Datenbank richtig mit den angegebenen Daten
aktualisiert wurde. Hierfür erstellen wir eine Instanz von
Zend_Test_PHPUnit_Db_DataSet_QueryDataSet
und geben Ihr eine
Datenbank Verbindung an. Dann sagen wir diesem Datenbank das er eine Tabelle "zfbugs"
enthält welche durch ein SQL Statement angegeben wird. Der aktuelle
Status der Datenbank wird mit dem erwarteten Datenbank Status vergleichen der in der
anderen XML Datei "bugsInsertIntoAssertions.xml" enthalten ist.
Diese XML Datei ist eine leichte Abwandlung von der oben angegeben,
und enthält eine weitere Zeile mit den erwarteten Daten:
<?xml version="1.0" encoding="UTF-8" ?> <dataset> <!-- previous 4 rows --> <zfbugs bug_id="5" bug_description="Something wrong" bug_status="NEW" created_on="2007-03-22 00:00:00" updated_on="2007-03-22 00:00:00" reported_by="garfield" assigned_to="mmouse" verified_by="garfield" /> </dataset>
Es gibt andere Wege um anzunehmen das der aktuelle Datenbank Status mit dem erwarteten Status gleich ist. Die Tabelle "Bugs" im Beispiel weiss bereits eine Menge über Ihren internen Status, warum dass also nicht zu unserem Vorteil nutzen? Das nächste Beispiel nimmt an dass das Löschen von der Datenbank möglich ist:
class BugsTest extends Zend_Test_PHPUnit_DatabaseTestCase { public function testBugDelete() { $bugsTable = new Bugs(); $bugsTable->delete( $bugsTable->getAdapter()->quoteInto("bug_id = ?", 4) ); $ds = new Zend_Test_PHPUnit_Db_DataSet_DbTableDataSet(); $ds->addTable($bugsTable); $this->assertDataSetsEqual( $this->createFlatXmlDataSet(dirname(__FILE__) . "/_files/bugsDeleteAssertion.xml"), $ds ); } }
Wir haben hier ein Datenset
Zend_Test_PHPUnit_Db_DataSet_DbTableDataSet
erstellt, welches
irgendweine Instanz von Zend_Db_Table_Abstract
nimmt, und diese
im Datenset mit Ihrem Tabellennamen hinzufügt, in diesem Beispiel "zfbugs". Man könnte
mehrere Tabellen hinzufügen, indem die Methode addTable()
verwendet wird, wenn man auf erwartete Datenbank Stati in mehr als einer Tabelle prüfen
will.
Hier haben wir nur eine Tabelle und prüfen auf den erwarteten Datenbank Status in "bugsDeleteAssertion.xml", welcher der originale Seed Datensatz ohne die Zeile mit der Id 4 ist.
Da wir im vorhergehenden Beispiel nur geprüft haben ob die zwei spezifischen Tabellen (nicht Datensätze) identisch sind, sollten wir uns auch anschauen wie man annehmen kann dass zwei Tabellen identisch sind. Hierfür fügen wir einen weiteren Test in unseren TestCase hinzu, der das Verhalten beim Aktualisieren eines Datensets prüft.
class BugsTest extends Zend_Test_PHPUnit_DatabaseTestCase { public function testBugUpdate() { $bugsTable = new Bugs(); $data = array( 'updated_on' => '2007-05-23', 'bug_status' => 'FIXED' ); $where = $bugsTable->getAdapter()->quoteInto('bug_id = ?', 1); $bugsTable->update($data, $where); $rowset = $bugsTable->fetchAll(); $ds = new Zend_Test_PHPUnit_Db_DataSet_DbRowset($rowset); $assertion = $this->createFlatXmlDataSet( dirname(__FILE__) . '/_files/bugsUpdateAssertion.xml' ); $expectedRowsets = $assertion->getTable('zfbugs'); $this->assertTablesEqual( $expectedRowsets, $ds ); } }
Hier haben wir den aktuellen Datenbank Status aus der Instanz eines
Zend_Db_Table_Rowset_Abstract
, in Verbindung mit der
Instanz von Zend_Test_PHPUnit_Db_DataSet_DbRowset($rowset)
erstellt, welche eine interne Daten-Repräsentation des Datensatzes erstellt. Das kann
wiederum gegenüber anderen Daten-Tabellen verglichen werden indem die Annahme
$this->assertTablesEqual()
verwendet wird.
Die Quickstart hat bereits eine gute Einführung darin gegeben wie Datenbank Tests durch
Verwendung von PHPUnit und Zend Framework durchgeführt werden können. Diese Sektion gibt
eine Übersicht über die API mit der die
Zend_Test_PHPUnit_Db
Komponente kommt und wie diese intern arbeitet.
Einige Hinweise über das Testen von Datenbanken
So wie der Controller TestCase eine Anwendung auf dem Level der Integration testet, ist der Datenbank TestCase eine Testmethode der Integration. Er verwendet mehrere unterschiedliche Anwendungs Layer für Testzwecke und sollte deswegen mit Vorsicht verwendet werden.
Es sollte darauf hingewiesen werden dass das Testen von Domain und Business Logik mit Integrationstests wie bei Zend Framework's Controller und Datenbank TestCases eine schlechte Praxis ist. Der Zweck von Integrationstests besteht darin zu Prüfen ob verschiedene Teile einer Anwendung problemlos arbeiten wenn Sie zusammen verknüpft werden. Diese Integrationstests ersetzen nicht die Notwendigkeit für ein Set von Unittests welche die Domain und Business Logik auf einem kleineren Level testen. Die isolierten Klassen.
Die Klasse Zend_Test_PHPUnit_DatabaseTestCase
ist von
PHPUnit_Extensions_Database_TestCase
abgeleitet welche es
erlaubt Tests mit einer frischen und fixen Datenbank einfach für jeden Lauf zu
erstellen. Die Implementation von Zend bietet einige bequeme zusätzliche Features
über die Database Erweiterung von PHPUnit wenn es zur Verwendung von
Zend_Db
in den eigenen Tests kommt. Der Workflow eines
Datenbank TestCases kann wie folgt beschrieben werden.
-
Für jeden Tests erstellt PHPUnit eine neue Instanz des TestCases und ruft die
setUp()
Methode auf. -
Der Datenbank TestCase erstellt eine Instanz eines Datenbank Testers welcher das Erstellen und Herunterfahren der Datenbank behandelt.
-
Der Datenbank Tester sammelt die Informationen der Datenbank Verbindung und des initialen Datensets von
getConnection()
undgetDataSet()
welche beide abstrakte Methoden sind und für jeden Datenbank TestCase implementiert werden. -
Standardmäßig schneidet der Datenbank Tester die Tabelle beim spezifizierten Datenset ab, und fügt dann die Daten ein die als initiales Fixum angegeben werden.
-
Wenn der Datenbank Tester damit fertig ist die Datenbank herzurichten, führt PHPUnit den Test durch.
-
Nachdem der Test gelaufen ist, wird
tearDown()
aufgerufen. Weil die Datenbank insetUp()
eingeflochten wird bevor das initiale Fixum eingefügt wurde, werden keine Aktionen vom Datenbank Tester auf dieser Ebene ausgeführt.
Anmerkung
Der Datenbank TestCase erwartet dass das Datenbank Schema und die Tabellen korrekt hergerichtet wurden um die Tests auszuführen. Es gibt keinen Mechanismus für die Erstellung und das Herunterfahren der Datenbank Tabellen.
Die Klasse Zend_Test_PHPUnit_DatabaseTestCase
hat einige
bequeme Funktionen die dabei helfen können Tests zu schreiben die mit der Datenbank
und der Datenbank Testerweiterung zu interagieren.
Die nächste Tabelle listet nur die neuen Methoden verglichen mit
PHPUnit_Extensions_Database_TestCase
auf, dessen API in der
Dokumentation von PHPUnit dokumentiert ist.
Tabelle 161. Die API Methoden von Zend_Test_PHPUnit_DatabaseTestCase
Methode | Beschreibung |
---|---|
createZendDbConnection(Zend_Db_Adapter_Abstract $connection,
$schema)
|
Erstellt eine mit der PHPUnit Datenbank Erweiterung kompatible Instanz
von einer Zend_Db_Adapter_Abstract Instanz.
Diese Methode sollte für das Setup der Testfälle verwendet werden wenn
die abstrakte getConnection() Methode des
Datenbank TestCases implementiert wird.
|
getAdapter() |
Bequeme Methode um auf die darunterliegende
Zend_Db_Adapter_Abstract Instanz zugreifen zu
können welche in der PHPUnit Datenbank Verbindung verknüpft ist die mit
getConnection() erstellt wurde.
|
createDbRowset(Zend_Db_Table_Rowset_Abstract $rowset,
$tableName = null)
|
Erstellt ein DataTable Objekt das mit den Daten aus einer angegebenen
Zend_Db_Table_Rowset_Abstract Instanz gefüllt
ist. Die Tabelle zu der die Zeile verbunden ist wird ausgewählt wenn
$tableName NULL ist.
|
createDbTable(Zend_Db_Table_Abstract $table, $where = null,
$order = null, $count = null, $offset = null)
|
Erstellt ein DataTable Objekt das die Daten repräsentiert wehcle in
einer Zend_Db_Table_Abstract Instanz enthalten
sind. Für das Empfangen der Daten wird
fetchAll() verwendet, wobei die optionalen
Parameter verwendet werden können um die Datentabelle auf eine
bestimmtes Untermenge zu begrenzen.
|
createDbTableDataSet(array $tables=array())
|
Erstellt ein DataSet das die angegebenen $tables
enthält, ein Array von Zend_Db_Table_Abstract
Instanzen.
|
Weil PHP die mehrfache Vererbung nicht unterstützt ist es nicht
möglich die Controller und Datenbank Testcases in Verbindung zu verwenden. Trotzdem
kann man den Zend_Test_PHPUnit_Db_SimpleTester
Datenbank
Tester im eigenen Controller Testcase verwenden um eine fixe Datenbankumgebung für
jeden neuen Controller Test zu erstellen. Der Datenbank TestCase ist generell nur
ein Set von bequemen Funktionen auf die auch zugegriffen und die auch ohne die
TestCases verwendet werden können.
Beispiel 898. Beispiele für die Integration der Datenbank
Dieses Beispiel erweitert den User Controller Test aus der
Zend_Test_PHPUnit_ControllerTestCase
Dokumentation um ein
Datenbank Setup zu inkludieren.
class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase { public function setUp() { $this->setupDatabase(); $this->bootstrap = array($this, 'appBootstrap'); parent::setUp(); } public function setupDatabase() { $db = Zend_Db::factory(...); $connection = new Zend_Test_PHPUnit_Db_Connection($db, 'database_schema_name'); $databaseTester = new Zend_Test_PHPUnit_Db_SimpleTester($connection); $databaseFixture = new PHPUnit_Extensions_Database_DataSet_FlatXmlDataSet( dirname(__FILE__) . '/_files/initialUserFixture.xml' ); $databaseTester->setupDatabase($databaseFixture); } }
Jetzt wird das flache XML Dataset "initialUserFixture.xml" verwendet um die Datenbank auf einen initialen Status vor jeden Test zu setzen, genauso wie DatabaseTestCase intern arbeitet.
Es gibt Zeiten in denen man Teile der eigenen Anwendung nicht mit einer echten Datenbank
testen will, aber wegen einer Kopplung dazu gezwungen ist.
Zend_Test_DbAdapter
bietet einen bequemen Weg um eine Implementation
von Zend_Db_Adapter_Abstract
zu verwenden ohne das eine Datenbank
Verbindung geöffnet werden muß. Weiters ist dieser Adapter einfach von innerhalb der
PHPUnit Testsuite zu verwenden, da er keine Constructor Argumente benötigt.
Der Test Adapter agiert als Stack für die verschiedenen Datenbank Ergebnisse. Die Reihenfolge der Ergebnisse muß auf Benutzerebene implementiert werden, was für Tests die viele unterschiedliche Datenbank Abfragen aufrufen ein arbeitsintensiver Task sein kann, aber er ist der richtige Helfer für Tests in denen nur eine Handvoll von Abfragen ausgeführt werden und man die exakte Reihenfolge der Ergebnisse kennt die vom Benutzerbezogenen Code zurückgegeben wird.
$adapter = new Zend_Test_DbAdapter(); $stmt1Rows = array(array('foo' => 'bar'), array('foo' => 'baz')); $stmt1 = Zend_Test_DbStatement::createSelectStatement($stmt1Rows); $adapter->appendStatementToStack($stmt1); $stmt2Rows = array(array('foo' => 'bar'), array('foo' => 'baz')); $stmt2 = Zend_Test_DbStatement::createSelectStatement($stmt2Rows); $adapter->appendStatementToStack($stmt2); $rs = $adapter->query('SELECT ...'); // Returns Statement 2 while ($row = $rs->fetch()) { echo $rs['foo']; // Prints "Bar", "Baz" } $rs = $adapter->query('SELECT ...'); // Returns Statement 1
Das Verhalten jedes realen Datenbank Adapters wird soweit wie möglich simuliert sodas
dessen Methoden, wie fetchAll()
,
fetchObject()
, fetchColumn
und weitere
für den Test Adapter funktionieren.
Man kann auch INSERT, UPDATE und DELETE Anweisungen im Ergebnis Stack platzieren, wobei
diese nur ein Ergebnis zurückgeben das es erlaubt das Ergebnis von
$stmt->rowCount()
zu spezifizieren.
$adapter = new Zend_Test_DbAdapter(); $adapter->appendStatementToStack( Zend_Test_DbStatement::createInsertStatement(1) ); $adapter->appendStatementToStack( Zend_Test_DbStatement::createUpdateStatement(2) ); $adapter->appendStatementToStack( Zend_Test_DbStatement::createDeleteStatement(10) );
Standardmäßig ist der Abfrage Profiler aktiviert, so dass man die ausgeführte SQL Anweisung und deren gebundene Parameter empfangen kann um diese auf Ihre Richtigkeit bei der Ausführung zu prüfen.
$adapter = new Zend_Test_DbAdapter(); $stmt = $adapter->query("SELECT * FROM bugs"); $qp = $adapter->getProfiler()->getLastQueryProfile(); echo $qp->getQuerY(); // SELECT * FROM bugs
Der Test Adapter prüft niemals ob die spezifizierte Anfrage die als nächstes vom Stack zurückgegeben wird wirklich vom Typ SELECT, DELETE, INSERT oder UPDATE ist. Die richtige Reihenfolge der zurückgegebenen Daten muss vom Benutzer des Test Adapters implementiert werden.
Der Test Adapter spezifiziert auch Methoden um die Verwendung der Methoden
listTables()
, describeTables()
und
lastInsertId()
simuliert. Wenn man
setQuoteIdentifierSymbol()
verwendet kann man spezifizieren welches
Symbol für die Kommentierung verwendet werden soll, da Standardmäßig keines verwendet wird.