Single Assert per Test

Kolumne: Quality Time
Kommentare

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 dem Gebiet 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 „Single 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. Sollte sich nun aufgrund einer Änderung diese Vorbedingung ändern, kommen wir in die folgende, irreführende Situation:

CollectionTestMultipleAssert::testAddIncreasesElements 
Failed asserting that 0>1>
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -