© saicle/Shutterstock.com
PHP Magazin
Kolumne: Quality Time

Single Assert per Test


Das Thema Software-Qualität hat in einem Großteil der professionellen PHP-Teams in Deutschland Einzug gehalten. Immer mehr Unternehmen erkennen die Vorteile von kontinuierlichen Qualit#tssicherungsmaßnahmen für Team, Management und Kunden. In unserer neuen „Quality Time“-Kolumne plaudern Experten auf demGebiet der Software-Qualität aus dem Nähkästchen: Neue interessante Tools, Diskussionen zu Methoden und Prozessen oder Tricks und Kniffe aus der alltäglichen Arbeit. Haben Sie ein Thema über das schon immer mal geschrieben werden sollte?Dann immer her damit – schicken Sie Ihre Anregungen an redaktion@phpmagazin.de.

Diese erste Kolumne möchte ich einem umstrittenen Prinzip der xUnit Patterns [1] widmen, dem „Sin­gle Assert per Test“. Dieses Prinzip besagt, dass jede Testmethode in einem automatisierten Test nur einen einzelnen assertXYZ()-Aufruf enthalten soll. Diese Aussage führt regelmäßig zu hitzigen Diskussionen, denn schließlich ist man so gezwungen, eine Vielzahl winziger und auf den ersten Blick unsinniger Testmethoden zu schreiben. Zusätzlich muss für jede einzelne Testmethode ein entsprechendes Testobjekt bzw. System Under Test (SUT) instanziiert und präpariert werden. Aus diesem und anderen Gründen wird das Single Assert-per-Test-Prinzip häufig als zu akademisch und dogmatisch abgetan und Testcode wie im folgenden Beispiel geschrieben:

class CollectionTestMultipleAssert extends PHPUnit_Framework_TestCase { public function testAddIncreasesElements() { $collection = new Collection(); $this->assertSame( 0, $collection->size() ); $collection->add( "X" ); $this->assertSame( 1, $collection->size() ); } public function testRemoveDecreasesElements() { $collection = new Collection(); $collection->add( "X" ); $this->assertSame( 1, $collection->size() ); $collection->remove( 0 ); $this->assertSame( 0, $collection->size() ); } }

Im Beispiel testen wir das Verhalten der add()- und remove()-Methoden einer fiktiven Collection-Klasse. Betrachtet man nun den Quelltext in den beiden Testmethoden, wird man auf den ersten Blick zu dem Schluss kommen, dass an dieser Stelle das Single-Assert-per-Test-Prinzip wirklich zu dogmatisch wäre – schließlich testet jede Methode ja genau einen Aspekt der Klasse. Auf den zweiten Blick stellt man aber fest, dass die Namen der Testmethoden doch nicht wirklich dem ausgeführten Quelltext entsprechen. So führt z. B. die testAddIncreasesElements()-Methode zusätzlich einen Check der Vorbedingung – Collection ist initial leer – durch. So...

PHP Magazin
Kolumne: Quality Time

Single Assert per Test

Das Thema Software-Qualität hat in einem Großteil der professionellen PHP-Teams in Deutschland Einzug gehalten. Immer mehr Unternehmen erkennen die Vorteile von kontinuierlichen Qualit#tssicherungsmaßnahmen für Team, Management und Kunden. In unserer neuen „Quality Time“-Kolumne plaudern Experten auf demGebiet der Software-Qualität aus dem Nähkästchen: Neue interessante Tools, Diskussionen zu Methoden und Prozessen oder Tricks und Kniffe aus der alltäglichen Arbeit. Haben Sie ein Thema über das schon immer mal geschrieben werden sollte?Dann immer her damit - schicken Sie Ihre Anregungen an redaktion@phpmagazin.de.

Manuel Pichler


Das Thema Software-Qualität hat in einem Großteil der professionellen PHP-Teams in Deutschland Einzug gehalten. Immer mehr Unternehmen erkennen die Vorteile von kontinuierlichen Qualit#tssicherungsmaßnahmen für Team, Management und Kunden. In unserer neuen „Quality Time“-Kolumne plaudern Experten auf demGebiet der Software-Qualität aus dem Nähkästchen: Neue interessante Tools, Diskussionen zu Methoden und Prozessen oder Tricks und Kniffe aus der alltäglichen Arbeit. Haben Sie ein Thema über das schon immer mal geschrieben werden sollte?Dann immer her damit – schicken Sie Ihre Anregungen an redaktion@phpmagazin.de.

Diese erste Kolumne möchte ich einem umstrittenen Prinzip der xUnit Patterns [1] widmen, dem „Sin­gle Assert per Test“. Dieses Prinzip besagt, dass jede Testmethode in einem automatisierten Test nur einen einzelnen assertXYZ()-Aufruf enthalten soll. Diese Aussage führt regelmäßig zu hitzigen Diskussionen, denn schließlich ist man so gezwungen, eine Vielzahl winziger und auf den ersten Blick unsinniger Testmethoden zu schreiben. Zusätzlich muss für jede einzelne Testmethode ein entsprechendes Testobjekt bzw. System Under Test (SUT) instanziiert und präpariert werden. Aus diesem und anderen Gründen wird das Single Assert-per-Test-Prinzip häufig als zu akademisch und dogmatisch abgetan und Testcode wie im folgenden Beispiel geschrieben:

class CollectionTestMultipleAssert extends PHPUnit_Framework_TestCase { public function testAddIncreasesElements() { $collection = new Collection(); $this->assertSame( 0, $collection->size() ); $collection->add( "X" ); $this->assertSame( 1, $collection->size() ); } public function testRemoveDecreasesElements() { $collection = new Collection(); $collection->add( "X" ); $this->assertSame( 1, $collection->size() ); $collection->remove( 0 ); $this->assertSame( 0, $collection->size() ); } }

Im Beispiel testen wir das Verhalten der add()- und remove()-Methoden einer fiktiven Collection-Klasse. Betrachtet man nun den Quelltext in den beiden Testmethoden, wird man auf den ersten Blick zu dem Schluss kommen, dass an dieser Stelle das Single-Assert-per-Test-Prinzip wirklich zu dogmatisch wäre – schließlich testet jede Methode ja genau einen Aspekt der Klasse. Auf den zweiten Blick stellt man aber fest, dass die Namen der Testmethoden doch nicht wirklich dem ausgeführten Quelltext entsprechen. So führt z. B. die testAddIncreasesElements()-Methode zusätzlich einen Check der Vorbedingung – Collection ist initial leer – durch. So...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang