Warum besteht PHPUnit darauf, Dinge auf die OO-Art zu tun?

Question

Auf die Gefahr hin, entflammt zu werden ... welchen Vorteil hat das Aufrufen von Methoden anstelle von Funktionen in einem Kontext, in dem der Kontext implizit ist.

Wenn man bedenkt, dass PHPs Syntax so hässlich ist, Methoden aufzurufen, warum haben die Entwickler von PHPUnit ihre Verwendung durchgesetzt?

Wenn der Rahmen gesetzt hatte, eine globale „currentTestCase“ Objekt und dann scheiterte transparent zugehörigen behauptet mit diesem Objekt, das wir schreiben könnte:

assertEquals("blah", $text); 

wie dem Ersatz dagegen, aber die ausführliche:

$this->assertEquals("blah", $text); 

Was genau bekommen wir mit OO in diesem Zusammenhang.

Bitte erleuchten Sie mich.

Answer 1

Weil PHPUnit von xUnit abgeleitet ist und so funktioniert xUnit.

Warum macht xUnit so? Ich bin froh, dass du gefragt hast. Der ursprüngliche Grund, wie Robert hervorhebt, ist, dass xUnit von Smalltalk stammt und von JUnit in Java popularisiert wurde. Beide sind OO-oder-nichts-Sprachen, also hatten sie keine Wahl.

Das soll nicht heißen, dass es keine anderen Vorteile gibt. OO-Tests können vererbt werden. Das bedeutet, wenn Sie eine Unterklasse testen möchten, können Sie alle Tests der Eltern ausführen und die wenigen Testmethoden für die von Ihnen geänderten Verhaltensweisen überschreiben. Dadurch erhalten Sie eine hervorragende Abdeckung der Unterklassen, ohne den Testcode duplizieren zu müssen.

Es ist einfach zu hinzufügen und überschreiben Assert-Methoden in PHPUnit. Einfach Unterklasse PHPUnit_Framework_TestCase, schreiben Sie Ihre eigenen assert Methoden und lassen Sie Ihre Testklassen von Ihrer neuen Unterklasse erben. Sie können auch die Standardmethoden setup und teardown schreiben.

Schließlich garantiert es, dass die Methoden des Test-Frameworks nicht mit der Sache, die sie testen, kollidieren werden. Wenn das Testframework gerade seine Funktionen in den Test geworfen hat und Sie etwas testen wollten, das eine setup Methode hatte ... nun, Sie sind in Schwierigkeiten.

Das heißt, ich höre deinen Schmerz. Ein großer Test-Framework kann nervig und umständlich und spröde sein. Perl verwendet keinen xUnit-Stil, es verwendet einen prozeduralen Stil mit kurzen Testfunktionsnamen. Ein Beispiel finden Sie in Test::More. Hinter den Kulissen tut es genau das, was Sie vorgeschlagen haben, es gibt ein Singleton-Testinstanzobjekt, das alle Funktionen verwenden. Es gibt auch eine hybride prozedurale Assert-Funktionen mit OO-Test-Methoden-Modul namens Test::Class, die das Beste aus beiden Welten tut.

Bedenkt man, dass die PHP-Syntax für den Aufruf von Methoden so hässlich ist

Ich denke, Sie nicht die -> mögen. Ich schlage vor, du lernst damit zu leben. OO PHP ist so viel schöner als die Alternative.

Answer 2

Ein guter Grund ist, dass assertXXX als Methodenname ein hohes Risiko für Namenskonflikt hat.

Eine andere ist, dass es von der xUnit Familie abgeleitet ist, die in der Regel mit objektorientierten Sprachen - Smalltalk zunächst behandelt. Dies macht es einfacher, sich mit Ihren "Geschwistern" in Verbindung zu setzen, z. Java und Ruby.

Answer 3

Die Testfälle in Klassenmethoden zu speichern spart Arbeit für PHPUnit. Mangels eingebauter Intelligenz konnte PHPUnit keine reinen Testfunktionen finden oder handhaben. Nur die -> assert *() -Nachrichten - in einer einfachen booleschen Kette - wiederzuerkennen, spart wiederum Verarbeitungslogik (für PHPUnit, nicht den Testfall-Autor). Es ist alles syntaktische Salz, das Overhead aus Sicht von PHPUnit/SimpleTest spart.

Es wäre kein technisches Problem, Fehler-/Warnmeldungen, Ausnahmen zu erfassen oder die native assert() -Anweisung von PHP zu erkennen. Es ist nicht getan, weil eine schwierige API mehr Enterprise aussieht.

Answer 4

Keine direkte Antwort, aber ab PHPUnit 3.5 müssen Sie nicht mehr $this-> schreiben. PHPUnit 3.5 hinzugefügt, um eine Funktionsbibliothek für Assertions, die Sie

require_once 'PHPUnit/Framework/Assert/Functions.php'; 

Dann können Sie

assertEquals('foo', $bar); 

See Sebastian Bergmann Blog Post tun aufzunehmen haben darüber

• http://sebastian-bergmann.de/archives/896-PHPUnit-3.5-Less-this-Required.html#content