nicht angemeldet
Hey dedlfix,
sorry, hat etwas länger gedauert, bis ich nun antworte. Aber ich kann's nicht oft genug sagen: Danke für Deine Hilfe!
Scheitert, wenn der Original-Code wegen OpCode-Compilern [...] nicht geändert werden kann.
Das verstehe ich leider nicht. Wie meinst Du das mit den OpCode-Compilern? In welcher Form spielen die eine Rolle für die Erweiterung des Original-Codes?War vielleicht etwas ungünstig formuliert. Der Original-Code ist der, den du schreibst. Wenn man den nicht offenlegen will, liefert man an Kunden vorkompilierten "Byte-Müll". Den kann der Kunde dann zwar verwenden, aber ihn nicht mehr ändern. Dan kann man natürlich als Kunde auch keine Erweiterungen mehr einpflegen.
Ah, verstanden!
Warum erschwert eine Factory das Testen?
Über eine Factory kann man im Allgemeinen nur aus einer feststehende Anzahl an "Produkten" wählen. Man kann ihr keine Mock-Objekte unterschieben. Vielmehr müsste man dann eine Test-Klasse schreiben, die sich in die Reihe der Produkte eingliedert. Damit ist man deutlich unflexibler als mit Mocks. So ein Mock definiert man ja on-the-fly innerhalb der Test-Methode - und in jeder Test-Methode mit unterschiedlichen Parametern und Reaktionen. Das kannst du mit einer Test-Produkt-Klasse kaum schaffen.
Danke für die Erklärung! Verstanden! :-)
Muss das ganze TDD-fähig sein? [...]
Ich wusste bis gerade nicht, was TDD bedeutet (für alle Unwissenden wie mich: Testgetriebene Entwicklung).Ausgeschrieben: Test Driven Development. Man schreibt sich zunächst für alle denkbaren und alle auszuschließenden Anwendungsfälle jeweils eine Methode, die diesen Anwendungsfall testet. Vom Testobjekt hat man zunächst nicht mehr als ein Gerippe - also Eigenschaften sind da, Methoden sind aber alle leer. Dann lässt man den Test zum ersten Mal laufen und stellt fest, dass alle Tests fehlschlagen. Sehr gut - nicht dass der Test an sich falsch implementiert ist und einfach so ein positives Ergebnis erzeugt. Nun füllt man das Gerippe mit Leben und schaut, wie der Test immer grüner wird. Für TDD gibt es Frameworks, die einen beim Schreiben solcher Tests unterstützen. Und die schon erwähnten Mocks sind dabei Helfer, die so tun, als seien sie Instanzen eines bestimmten Interfaces, das vom zu testenden Objekt verwendet wird.
Das hört sich echt interessant an. Da muss ich mich glaub ich mal was länger mit auseinandersetzen. Scheint ja relativ komplex (und kompliziert) zu sein.
Also, die Config-Klasse soll getestet werden. Die will per DI ein Objekt einer Klasse mit implementiertem Quellen-Interface haben, aus dem sie sich die Konfigurationswerte holen kann. Man nimmt für den Test nun keine Test-Klasse sondern ein Mock-Objekt. Das tut so, als hätte es das Quellen-Interface implementiert und wird so initialisiert, dass beim Aufruf einer der im Interface vereinbarten Methoden ein bestimmter Wert zurückgegeben wird. Nun veranlasst man die Config-Klasse, dass sie etwas macht, das genau diese Methode im angeblichen Quellen-Objekt aufruft und kann dann schauen, wie die Konfig-Klasse auf unterschiedliche vom Mock-Objekt bereitgestellte Rückgabewerte reagiert. Hört sich komplex an? Isses auch. Aber es gibt nicht nur Test-Frameworks sondern auch fertige Mock-Implementationen. (Wobei ich aber für PHP keine aktuelle Marktübersicht habe.)
Auch für diese Erklärung vielen Dank. Ich verstehe zwar, worum es prinzipiell geht, aber da muss ich mich erstmal näher mit beschäftigen.
Ist PhpUnit so ein Test-Framework?
Komplexer und komplizierter geht immer. Zum Beispiel könnte man statt eines (verschachtelten) Arrays in der Config-Klasse weiteren Klassen vorsehen, die im einfachsten Fall einen Wert aber auch andere individuelle Strukturen enthalten können.
Wenn ich Dich richtig verstehe, versuchen wir das bereits. Ich hab mal eine Zip-Datei mit einer anfänglichen und unfertigen (was für ein tolles Wort...) Version einer möglichen Config-Implementierung hochgeladen.Darin sehe ich von meinem Beispiel nichts. [...]
Kannst Du auch nicht. Hab an was ganz anderes gedacht...
(Vorschläge natürlich sehr erwünscht): http://fsac.de/dat/selfhtml/library.zip
Dedlfix, ich hab Dir leider eine falsche Version hochgeladen. Die hatte ich vor ein paar Wochen mal um ein paar Dinge zu testen erstellt. Sorry!
Aber Deine Hinweise haben mir trotzdem sehr geholfen (und ich bin froh, dass ich die neuere Version nicht hochgeladen hab - Du hättest wahrscheinlich nicht ruhig schlafen können :-) ).
Ich hab jetzt unter oben genanntem Link mal eine neue Version hochgeladen, die ich eben mal gemacht habe. Wenn Du Zeit und Lust hast, würde ich mich freuen, wenn Du nochmal kurz drüberschauen könntest. Da ist zwar noch nichts kommentiert und das ist bei weitem noch nicht fertig; aber vielleicht kannst Du mir kurz sagen, ob das jetzt Dependency Injection ist, was ich verwendet habe!?
Danke, dass Du Dir die Zeit nimmst, mir beim Lernen zu helfen!
Dennis