Unit-Testkonzept bei privaten / protected Methoden

mr.luke · 14.04.2011, 13:29

Mahlzeit...

Ich hatte heute eine kurze Diskussion bzgl. dem richtigen Vorgehen bei Unittest. Es handelt sich um folgenden Fall.

PHP-Code:

  class UnitTestingFooBarBaz {

      public function parentMethod($array, $object, $string)

      {

            // geprüft wird, ob array, object und string übergeben werden

            // ...

 
            // hier ist der Diskussionspunkt

            $var = $this->_childPeter();

 
            // ... Foo

            // ... Bar

            // ... Baz

 
            // hier ist der Diskussionspunkt

            $var = $this->_childKlaus();

      }

 
      protected function _childPeter() { return 'Peter'; }

      protected function _childKlaus() { return 'Klaus'; }

}

Meiner Meinung nach sollte in einem Unittest die Funktion "parentMethod(...)" als unabhängige Komponente getestet werden. Es existieren innerhalb der Funktion Abhängigkeiten auf Basis der zwei privaten / protected Funktionen der Klasse.

Persönlich würde ich diese Funktionen komplett "mocken" und folgendes Testen....
1. Was passiert wenn die gemockte Funktion eine Exception wirft
2. Nix / Null returned
3. Ein falsches Datenformat / falschen Datentypen returned
4. Fehlerfrei funktioniert.

Damit wäre auch eine max. Code Coverage möglich, ohne die private / protected Funktion per Reflections auf public zu wandeln.

Natürlich würde es auch einen Integrationstest geben, in welchem die Funktion tatsächlich auch aufgerufen wird. Nur in diesem Integrationstest will ich die funktionierenden Abhängigkeiten testen.

Liege ich damit richtig oder nicht? ... Feedback / Tipps?

Gruß,
Mr.Luke

mepeisen · 14.04.2011, 14:59

Generell sollte man immer a) pro Klasse und b) pro Methode testen. Es spricht nichts dagegen, parentMethod als solches zu testen ohne zu mocken. Voraussetzung: Man testet childPeter und childKlaus, sowie etwaige ifs etc. darin auch wirklich nochmal separat durch. Ich persönlich tendiere immer dazu, nur die externen Klassenabhängigkeiten zu mocken bei Unit-Tests. Abhängigkeiten, die sich aus privaten/protected Methoden oder aus Vererbungen ergeben, werden nicht separat gemockt. Das ist jedoch eine Frage der Philosophie oder der Paranoia.

Testfälle sind ja immer im Gut-Fall aufgebaut. Heisst: Wenn du nicht erwartest, dass _childPeter eine Exception wirft, dann brauchst du das auch in parentMethod nicht prüfen. Testest du _childPeter alleine, stellt PhpUnit sicher, dass unerwartete Exceptions auf einen Fehler laufen und damit ist das Thema erledigt. Ob parentMethod damit richtig umgeht, kann dir eigentlich egal sein, da _childPeter den Vertrag nicht eingehalten hat und damit auch der Fehler woanders liegt.
Ist _childPeter hingegen beispielsweise eine DB-Zugriffsmethode, die eine Exception werfen darf (NoConnection oder sowas), dann musst du auch verifizieren, wie parentMethod mit dieser Exception "klar kommt". Egal ob du nun _childPeter mockst um diese Exception zu werfen (was im Zweifelsfall wohl die klügste Variante ist) oder ob du was anderes mockst um den regulären Code aus _childPeter die Exception werfen zu lassen.

Natürlich bauen Unit-Tests immer auf zwei Dingen auf:
- Den Vertrag (Api-Beschreibung u.ä.), den eine Klasse bzw. Methode eingeht
- Der Arbeitsweise in der Methode
Alle anderen Ansätze, also beispielsweise fachliche Tests, dienen nicht dazu, eine hohe Code-Abdeckung zu erreichen, sondern sind logisch begründete Tests zum Zusammenspiel mehrerer Komponenten. Streng genommen sind das keine Unit-Tests mehr, auch wenn man sie technisch per PhpUnit abbildet

agrajag · 14.04.2011, 18:36

Wie würdest du es denn Mocken? Da müsstest du ja einen Mock der eigentlich zu testenden Klasse anlegen? Oder willst du das Ding ableiten und die protected-Methoden mit einer Mock-Implementierung überschreiben?

In meinen Augen:

Wenn du hier anfängst private und protected-Methoden zu mocken (wie auch immer) testest du nicht mehr nur die externe Schnittstelle sondern dein Test macht ziemlich genaue Annahmen darüber wie das ganze implementiert ist. So verlierst du den Vorteil den dir Unit-Testen eigentlich bringen soll:
Du schreibst den Test, bringst das Ding irgendwie zum laufen und danach refactorest du das ganze und trimmst es auf "schön" und kuckst nur dass der Test noch läuft.....

Wenn _childPeter/_childKlaus für dich wirklich eine "Abhängigkeit" sind, dann solltest du dich vielleicht fragen ob es dann überhaupt in diese Klasse gehört oder ob es nicht eine neue Klasse braucht die wiederum einzeln testbar ist.....

mepeisen · 14.04.2011, 19:42

Normalerweise genau das erstere, also die zu testende Klasse mocken und gezielt die beiden Methoden dabei überschreiben.

Das mit den Abhängigkeiten sehe ich prinzipiell auch anders. Das liegt aber am Testansatz. Betrachtest du deine Klasse als API und willst die öffentliche Schnittstelle testen oder willst du eine komplexe Implementierung testen? Im Prinzip sollte man immer beides machen. Unit-Tests gehen auf Komponentenebene, auf Klassenebene aber ebend - wie der Autor es machen will - auf Methodenebene.
Ich gehe generell so vor:
1. Testen auf Methodenebene
2. Testen auf Klassenebene (Zusammenspiel der Methoden)
3. Testen auf Komponentenebene (Zusammenspiel mehrerer Klassen einer Komponente)
4. Testen auf fachlicher Ebene (Selenium/Bildschirme usw.)

mr.luke · 14.04.2011, 20:38

Dem zweiten Post von mepeisen stimme ich zu, obwohl ich nicht die Kernaussage der ersten Antwort verstehe ... wahrscheinlich gibt sein zweiter Post aber genau diese wieder.

Hier nochmals meine Meinung .... da der Anfangspost eigentlich mehr eine Frage war.
Wenn ich von ext. Methoden sprechen, dann können dies z.B. eigene Klassenmethoden sein... aber auch anderen abstrakte Sachen.
Soll nur die Abhängigkeit darstellen, daher die Info.

1. Schritt / Ebene
Hier interessiert mich eigentlich nur, ob mein Modul (die Funktion) eigenständig fehlerfrei funktioniert.... d.h. dieser muss unabhängig von externen Quellen (z.B. einer anderen Methoden oder sonstigem Foo) fehlerfrei sein. Ich würde daher die ext. Methode mit allen möglichen Ausprägungen "mocken".

Ich persönlich kann, bei Eintritt eines Fehlerfalls, dann genauer prüfen.... ob meine Funktion ohne die "gemockten" externen Methoden / Abhängigkeiten falsch ist. Sonst müsste ich noch die genutzten Methoden prüfen, da der Fehler auch dadurch verursacht werden könnte... also per Hand alle durchgehen.

Dies ist für mich die strikte, aber realistische Interpretation eines unabhängigen Modultests.... d.h. die kleine mögliche Unit und nicht mehr.

2. Schritt / Ebene
Ich führe die ext. Methoden über eine reelle Instanz aus und validiere die tatsächlichen existierenden Rückgabewerte. Meine Methode, muss sich dann identisch zu den Modultests verhalten... ansonsten stimmt etwas mit den Tests bzw. der Methode nicht.

Die weiteren Ebenen spare ich mir jetzt

Vielen Dank für die Antworten .... mal ein gutes Gespräch / Texten, welches sich nicht nur um Systemdesign / -entwurf und diesem ganzen Bla Bla Bla dreht

))

Zum Schluss.... habt ihr vielleicht gute Links?
Kenne nur bekannten Slides der PHP.CC ... sonst tatsächlich leider nix.

Gruß,
Luke

agrajag · 14.04.2011, 23:34

Ich bleib dabei: private Methoden werden nicht (direkt) getestet und auch nicht gemockt. Wenn du das ganze hier nur als vereinfachtest Beispiel drin hast und der Aufruf $this->_childKlaus() in Wirklichkeit ein $someObjest->someMethod() ist - dann ist es natürlich richtig/ok einen Stub zu verwenden.
Aber wenn der Code tatsächlich so aussieht wie oben: Nicht mocken/stubben. Warum? Weil du dann natürlich auch die private/protected-Methode irgendwie (isoliert) testen musst.

Oder nochmal anders: Angenommen du entwickelst das ganze Testdriven: Methode parentMethod() soll eine bestimme Aufgabe erledigen. Du schreibst den ersten Test und daraufhin den ersten Code. Dann den nächsten Test und den nächsten Code usw. Das heißt du schreibst wirklich nur Code um den Test zum laufen zu kriegen. Wenn du jetzt irgendwann im Zuge eines refactoring etwas Code in eine protected-Methode auslagerst gibt es keinen Grund etwas zu mocken oder auch nur einen neuen Test zu schreiben.... .

Vielleicht ist aber auch nur dein Beispiel schlecht gewählt bzw. ich verstehe es falsch.....

Und ganz unabhängig vom "sollte man das machen": Wie würde das in PhpUnit aussehen? Die zu testende Klasse mocken?

mepeisen · 15.04.2011, 00:50

Kann nur von Flow3 sprechen, das leitet das aber im Prinzip auch an die Mocking-Tools von PhpUnit weiter. Vom Grundprinzip her kannst beim Mock in Flow3 (und hoffentlich damit in PhPUnit selbst) angeben, welche Methoden gemockt werden. Das sieht dann etwa so aus:

PHP-Code:

  $mock = $this->getMock('MyClass', array('_childPeter'));

$mock->expect('_childPeter')->will($this->return('Peter'));

 
// testfall auf die andere Methode

Hab gerade so spät keine Lust Eclipse aufzumachen ums genau anzugucken, daher ist die Syntax evtl. nicht hundert prozent richtig

Aber es geht ja nur um eine theoretische Diskussion und nicht um lauffähigen Code.

Wie ich Eingangs bereits sagte. Wenn man Unit-Tests auf Methodenebene macht und dazu die abhängigen Methoden mocken will, spricht nichts dagegen. Und natürlich musst du die gemockten nochmal isoliert ine inem zweiten Tesfall testen, sagte ich auch bereits (auch wenns erste Post evtl. unverständlich war).

Es ist eine Frage der Philosophie. Je feiner und kleiner die zu testende Unit ist, desto leichter findet man Fehler, desto höher ist der Testabdeckungsgrad (alles positiv). Aber: Desto höher ist der Aufwand, desto höher ist der notwendige Umbau bei Umbau der zu testenden Klassen (alles negativ).

Aber das sind gefühlte Faktoren, keine harten No-Gos. Wer sich en Aufwand machen will, wer sich (wie beim Zend Framework beispielsweise) eine 100% Code-Abdeckung in den Kopf gesetzt hat, der wird deutlich feiner aufgebaute Testfälle haben.

Was man nie machen sollte: Das große Ganze zu vernachlässigen. Selbst wenn jede Methode für sich getestet wurde, sollte man immer auch noch Testfälle machen, die die gesamte Klasse testen. Man sollte Testfälle machen, die eine ganze Komponente, also mehrere Klassen testen. Aus zwei Gründen: Nach einem größeren Umbau hat man zumindest noch diese größeren Testfälle, die funktionieren müssen. Und zudem treten viele Fehler auch erst auf, wenn die Klassen miteinander agieren. Bei feinen Unit-Tests auf Methodenebene werden immer mal Konstellationen übersehen.

Aber mal einen praktischen Nutzen davon:
-> Gegeben sei eine abstrakte Datenbank-Basisklasese. Diese kann eine Entität aus einer Datenbanktabelle auslesen und in sie zurückschreiben.
-> Um die ID eines Objektes rauszufinden interagiert diese Basisklasse relativ komplex mit der Persistenzschicht (Neues Objekt? Gelöschtes Objekt? usw.)
Wenn man nun die Datenbankzugriffsklasse testet und eine andere Methode im Sinn hat, die lediglich die ID des Objektes abfragt um damit weiter zu hantieren, hat man die Wahl zwischen:
a) Mocken der Persistenzschicht inklusive der 10 Aufrufe dahin.
b) Mocken der Methode "GetID" um eine erwartete ID einfach direktzurückzugeben und damit die eigentliche Methode hantieren zu lassen.
Dass GetID die richtige ID aus der Persistenzschicht abfragt, das wird von separaten Testfällen des Basisframeworks abgedeckt und ist dami nicht im Fokus der eigenen Testfälle.

Ich hoffe, dass dieses Beispiel das Mocken von zumindest protected Methoden rechtfertigt. Im Extremfall auch das Mocken von Private-Methoden.

mr.luke · 15.04.2011, 07:34

Moin ... Moin ...

Sorry, konnte mir bis jetzt noch nicht alle Antworten genau durchlesen.
Deshalb nur eine kurze Antwort auf die Frage: Wie sind die anderen privaten / protected Methoden getestet?

Natürlich gehe ich davon aus, dass diese getestet sind.
Man sollte schliesslich auch für jede Methode eigene Unittests haben... ist dies nicht der Fall, so testet man über die parentMethod() die UnterMethoden, d.h. diese werden dann wahrscheinlich für sich selbst nicht eigenständig getestet.

Für mich ein NoGo, denn was passiert, wenn die Methode z.B. bei unterschiedliche Results liefert und aus 7 unters. parentMethods() aufgerufen wird und sich entsprechend unterschiedlich verhält. Natürlich muss / sollte man dies refactorn, aber dies ist ein anderes Thema

Fortsetzung folgt...

agrajag · 15.04.2011, 09:17

Zitat:

Zitat von mepeisen

Kann nur von Flow3 sprechen, das leitet das aber im Prinzip auch an die Mocking-Tools von PhpUnit weiter. Vom Grundprinzip her kannst beim Mock in Flow3 (und hoffentlich damit in PhPUnit selbst) angeben, welche Methoden gemockt werden. Das sieht dann etwa so aus:

PHP-Code:

  $mock = $this->getMock('MyClass', array('_childPeter'));

$mock->expect('_childPeter')->will($this->return('Peter'));

 
// testfall auf die andere Methode

Ok. Als ich es das letze mal ausprobiert hatte, habe ich es ohne den zweiten Parameter für getMock() ausprobiert. Technisch geht es also. Ich find's trotzdem etwas "fishy" jetzt irgendwelche Tests auf diesem Mock auszuführen....

PHP-Code:

  $this->assertEquals('xy', $mock->getSomething());

fühlt sich für mich einfach nicht richtig an....

PHP-Code:

  Wie ich Eingangs bereits sagte. Wenn man Unit-Tests auf Methodenebene macht und dazu die abhängigen Methoden mocken will, spricht nichts dagegen. Und natürlich musst du die gemockten nochmal isoliert ine inem zweiten Tesfall testen, sagte ich auch bereits (auch wenns erste Post evtl. unverständlich war).

Dann testet du also wirklich auch protected und private-Methoden? Wie machst du das mit Flow3 bzw PHPUnit?

Zu deinem Beispiel:
Ich sehe schon den Nutzen davon. Aber meiner Meinung nach läuft man da schnell Gefahr einen bzw. mehrere der Vorteile von Unit-Tests kaputt zu machen:
- das leichte refactoren (je mehr dein test von der internen Implementierung weiß desto schwieriger)
- die Auswirkugnen auf gutes Design. Bei deinem Beispiel könnte man sich zum Beispiel fragen: Warum muss ich 10 Methoden mocken? Macht die Klasse dann nicht schon zuviel? Muss getId() vielleicht in eine andere Klasse? usw. usf.

Zitat:

Für mich ein NoGo, denn was passiert, wenn die Methode z.B. bei unterschiedliche Results liefert und aus 7 unters. parentMethods() aufgerufen wird und sich entsprechend unterschiedlich verhält. Natürlich muss / sollte man dies refactorn, aber dies ist ein anderes Thema

Für mich ist das eben kein anderes Thema sondern genau das ist das (oder auch ein) Thema.

mepeisen · 15.04.2011, 13:37

Zitat:

Zitat von agrajag

Dann testet du also wirklich auch protected und private-Methoden? Wie machst du das mit Flow3 bzw PHPUnit?

Da bei mir zur Zeit etwa die Hälfte des Codes aus einem UML-Generator rauspurzelt fallen auch die Hälfte der Testfälle da raus

Im Ernst. Ich definiere zuerst das Testziel. Und baue darauf die Tests auf. In vielen meiner Projekte habe ich den Anspruch, 100% Code-Abdeckung zu erreichen. Dennoch entscheide ich von Fall zu Fall ob mehrere Methoden gemeinsam getestet werden oder ebend nicht.

Die API zu testen und damit quasi ohne Implementierungswissen zu testen, kommt immer zusätzlich oben drauf. Ich teste gewissermassen beides: Sowohl die Klasse, wie sie als Blackbox funktionieren sollte, als auch die Implementierung dahinter. Ich bin mir bewusst, dass dies bei einem Refactoring zusätzlichen Aufwand bedeutet.

Aber generell gilt bis zu einem gewissen Grad (Ja, irgendwann wirds kontraproduktiv): Den Aufwand, den man am Anfang in einen Testfall reinsteckt, den spart man sich bei Erweiterungen und bei der Wartung usw.
Refactoring ist für mich kein Argument, da ich generell nur 10%, maximal 20% meines Codes jemals einem Refactoring unterwerfe (Leistungserweiterungen, wie neue Attribute in einer Entität zähle ich mal nicht zum Refactoring).

Zitat:

- die Auswirkugnen auf gutes Design. Bei deinem Beispiel könnte man sich zum Beispiel fragen: Warum muss ich 10 Methoden mocken? Macht die Klasse dann nicht schon zuviel? Muss getId() vielleicht in eine andere Klasse? usw. usf.

Schon klar, ist auch eventuell übertrieben. Aber es geht mir ums Prinzip. Es kann durchaus gerade bei abgeleiteten Methoden Sinn machen, diese zu mocken, wenn man sichergehen kann, dass sie separaten Testfällen unterworfen sind.

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
performante Verknüpfung von Tabellen??	Gimpel	Datenbanken	13	27.02.2010 14:57

14.04.2011, 13:29
mr.luke Neuer Benutzer Registriert seit: 29.10.2008 Beiträge: 5 PHP-Kenntnisse: Fortgeschritten	Unit-Testkonzept bei privaten / protected Methoden Mahlzeit... Ich hatte heute eine kurze Diskussion bzgl. dem richtigen Vorgehen bei Unittest. Es handelt sich um folgenden Fall. PHP-Code: class UnitTestingFooBarBaz { public function parentMethod($array, $object, $string) { // geprüft wird, ob array, object und string übergeben werden // ... // hier ist der Diskussionspunkt $var = $this->_childPeter(); // ... Foo // ... Bar // ... Baz // hier ist der Diskussionspunkt $var = $this->_childKlaus(); } protected function _childPeter() { return 'Peter'; } protected function _childKlaus() { return 'Klaus'; } } Meiner Meinung nach sollte in einem Unittest die Funktion "parentMethod(...)" als unabhängige Komponente getestet werden. Es existieren innerhalb der Funktion Abhängigkeiten auf Basis der zwei privaten / protected Funktionen der Klasse. Persönlich würde ich diese Funktionen komplett "mocken" und folgendes Testen.... 1. Was passiert wenn die gemockte Funktion eine Exception wirft 2. Nix / Null returned 3. Ein falsches Datenformat / falschen Datentypen returned 4. Fehlerfrei funktioniert. Damit wäre auch eine max. Code Coverage möglich, ohne die private / protected Funktion per Reflections auf public zu wandeln. Natürlich würde es auch einen Integrationstest geben, in welchem die Funktion tatsächlich auch aufgerufen wird. Nur in diesem Integrationstest will ich die funktionierenden Abhängigkeiten testen. Liege ich damit richtig oder nicht? ... Feedback / Tipps? Gruß, Mr.Luke


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

14.04.2011, 14:59
mepeisen Erfahrener Benutzer Registriert seit: 21.12.2004 Beiträge: 5.235 PHP-Kenntnisse: Fortgeschritten	Generell sollte man immer a) pro Klasse und b) pro Methode testen. Es spricht nichts dagegen, parentMethod als solches zu testen ohne zu mocken. Voraussetzung: Man testet childPeter und childKlaus, sowie etwaige ifs etc. darin auch wirklich nochmal separat durch. Ich persönlich tendiere immer dazu, nur die externen Klassenabhängigkeiten zu mocken bei Unit-Tests. Abhängigkeiten, die sich aus privaten/protected Methoden oder aus Vererbungen ergeben, werden nicht separat gemockt. Das ist jedoch eine Frage der Philosophie oder der Paranoia. Testfälle sind ja immer im Gut-Fall aufgebaut. Heisst: Wenn du nicht erwartest, dass _childPeter eine Exception wirft, dann brauchst du das auch in parentMethod nicht prüfen. Testest du _childPeter alleine, stellt PhpUnit sicher, dass unerwartete Exceptions auf einen Fehler laufen und damit ist das Thema erledigt. Ob parentMethod damit richtig umgeht, kann dir eigentlich egal sein, da _childPeter den Vertrag nicht eingehalten hat und damit auch der Fehler woanders liegt. Ist _childPeter hingegen beispielsweise eine DB-Zugriffsmethode, die eine Exception werfen darf (NoConnection oder sowas), dann musst du auch verifizieren, wie parentMethod mit dieser Exception "klar kommt". Egal ob du nun _childPeter mockst um diese Exception zu werfen (was im Zweifelsfall wohl die klügste Variante ist) oder ob du was anderes mockst um den regulären Code aus _childPeter die Exception werfen zu lassen. Natürlich bauen Unit-Tests immer auf zwei Dingen auf: - Den Vertrag (Api-Beschreibung u.ä.), den eine Klasse bzw. Methode eingeht - Der Arbeitsweise in der Methode Alle anderen Ansätze, also beispielsweise fachliche Tests, dienen nicht dazu, eine hohe Code-Abdeckung zu erreichen, sondern sind logisch begründete Tests zum Zusammenspiel mehrerer Komponenten. Streng genommen sind das keine Unit-Tests mehr, auch wenn man sie technisch per PhpUnit abbildet __________________ www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

14.04.2011, 18:36
agrajag Moderator Registriert seit: 02.10.2006 Beiträge: 3.820 PHP-Kenntnisse: Fortgeschritten	Wie würdest du es denn Mocken? Da müsstest du ja einen Mock der eigentlich zu testenden Klasse anlegen? Oder willst du das Ding ableiten und die protected-Methoden mit einer Mock-Implementierung überschreiben? In meinen Augen: Wenn du hier anfängst private und protected-Methoden zu mocken (wie auch immer) testest du nicht mehr nur die externe Schnittstelle sondern dein Test macht ziemlich genaue Annahmen darüber wie das ganze implementiert ist. So verlierst du den Vorteil den dir Unit-Testen eigentlich bringen soll: Du schreibst den Test, bringst das Ding irgendwie zum laufen und danach refactorest du das ganze und trimmst es auf "schön" und kuckst nur dass der Test noch läuft..... Wenn _childPeter/_childKlaus für dich wirklich eine "Abhängigkeit" sind, dann solltest du dich vielleicht fragen ob es dann überhaupt in diese Klasse gehört oder ob es nicht eine neue Klasse braucht die wiederum einzeln testbar ist..... __________________ Today you...Tomorrow me.

14.04.2011, 19:42
mepeisen Erfahrener Benutzer Registriert seit: 21.12.2004 Beiträge: 5.235 PHP-Kenntnisse: Fortgeschritten	Normalerweise genau das erstere, also die zu testende Klasse mocken und gezielt die beiden Methoden dabei überschreiben. Das mit den Abhängigkeiten sehe ich prinzipiell auch anders. Das liegt aber am Testansatz. Betrachtest du deine Klasse als API und willst die öffentliche Schnittstelle testen oder willst du eine komplexe Implementierung testen? Im Prinzip sollte man immer beides machen. Unit-Tests gehen auf Komponentenebene, auf Klassenebene aber ebend - wie der Autor es machen will - auf Methodenebene. Ich gehe generell so vor: 1. Testen auf Methodenebene 2. Testen auf Klassenebene (Zusammenspiel der Methoden) 3. Testen auf Komponentenebene (Zusammenspiel mehrerer Klassen einer Komponente) 4. Testen auf fachlicher Ebene (Selenium/Bildschirme usw.) __________________ www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

14.04.2011, 20:38
mr.luke Neuer Benutzer Registriert seit: 29.10.2008 Beiträge: 5 PHP-Kenntnisse: Fortgeschritten	Dem zweiten Post von mepeisen stimme ich zu, obwohl ich nicht die Kernaussage der ersten Antwort verstehe ... wahrscheinlich gibt sein zweiter Post aber genau diese wieder. Hier nochmals meine Meinung .... da der Anfangspost eigentlich mehr eine Frage war. Wenn ich von ext. Methoden sprechen, dann können dies z.B. eigene Klassenmethoden sein... aber auch anderen abstrakte Sachen. Soll nur die Abhängigkeit darstellen, daher die Info. 1. Schritt / Ebene Hier interessiert mich eigentlich nur, ob mein Modul (die Funktion) eigenständig fehlerfrei funktioniert.... d.h. dieser muss unabhängig von externen Quellen (z.B. einer anderen Methoden oder sonstigem Foo) fehlerfrei sein. Ich würde daher die ext. Methode mit allen möglichen Ausprägungen "mocken". Ich persönlich kann, bei Eintritt eines Fehlerfalls, dann genauer prüfen.... ob meine Funktion ohne die "gemockten" externen Methoden / Abhängigkeiten falsch ist. Sonst müsste ich noch die genutzten Methoden prüfen, da der Fehler auch dadurch verursacht werden könnte... also per Hand alle durchgehen. Dies ist für mich die strikte, aber realistische Interpretation eines unabhängigen Modultests.... d.h. die kleine mögliche Unit und nicht mehr. 2. Schritt / Ebene Ich führe die ext. Methoden über eine reelle Instanz aus und validiere die tatsächlichen existierenden Rückgabewerte. Meine Methode, muss sich dann identisch zu den Modultests verhalten... ansonsten stimmt etwas mit den Tests bzw. der Methode nicht. Die weiteren Ebenen spare ich mir jetzt Vielen Dank für die Antworten .... mal ein gutes Gespräch / Texten, welches sich nicht nur um Systemdesign / -entwurf und diesem ganzen Bla Bla Bla dreht )) Zum Schluss.... habt ihr vielleicht gute Links? Kenne nur bekannten Slides der PHP.CC ... sonst tatsächlich leider nix. Gruß, Luke

14.04.2011, 23:34
agrajag Moderator Registriert seit: 02.10.2006 Beiträge: 3.820 PHP-Kenntnisse: Fortgeschritten	Ich bleib dabei: private Methoden werden nicht (direkt) getestet und auch nicht gemockt. Wenn du das ganze hier nur als vereinfachtest Beispiel drin hast und der Aufruf $this->_childKlaus() in Wirklichkeit ein $someObjest->someMethod() ist - dann ist es natürlich richtig/ok einen Stub zu verwenden. Aber wenn der Code tatsächlich so aussieht wie oben: Nicht mocken/stubben. Warum? Weil du dann natürlich auch die private/protected-Methode irgendwie (isoliert) testen musst. Oder nochmal anders: Angenommen du entwickelst das ganze Testdriven: Methode parentMethod() soll eine bestimme Aufgabe erledigen. Du schreibst den ersten Test und daraufhin den ersten Code. Dann den nächsten Test und den nächsten Code usw. Das heißt du schreibst wirklich nur Code um den Test zum laufen zu kriegen. Wenn du jetzt irgendwann im Zuge eines refactoring etwas Code in eine protected-Methode auslagerst gibt es keinen Grund etwas zu mocken oder auch nur einen neuen Test zu schreiben.... . Vielleicht ist aber auch nur dein Beispiel schlecht gewählt bzw. ich verstehe es falsch..... Und ganz unabhängig vom "sollte man das machen": Wie würde das in PhpUnit aussehen? Die zu testende Klasse mocken? __________________ Today you...Tomorrow me.

15.04.2011, 00:50
mepeisen Erfahrener Benutzer Registriert seit: 21.12.2004 Beiträge: 5.235 PHP-Kenntnisse: Fortgeschritten	Kann nur von Flow3 sprechen, das leitet das aber im Prinzip auch an die Mocking-Tools von PhpUnit weiter. Vom Grundprinzip her kannst beim Mock in Flow3 (und hoffentlich damit in PhPUnit selbst) angeben, welche Methoden gemockt werden. Das sieht dann etwa so aus: PHP-Code: `$mock = $this->getMock('MyClass', array('_childPeter')); $mock->expect('_childPeter')->will($this->return('Peter')); // testfall auf die andere Methode` Hab gerade so spät keine Lust Eclipse aufzumachen ums genau anzugucken, daher ist die Syntax evtl. nicht hundert prozent richtig Aber es geht ja nur um eine theoretische Diskussion und nicht um lauffähigen Code. Wie ich Eingangs bereits sagte. Wenn man Unit-Tests auf Methodenebene macht und dazu die abhängigen Methoden mocken will, spricht nichts dagegen. Und natürlich musst du die gemockten nochmal isoliert ine inem zweiten Tesfall testen, sagte ich auch bereits (auch wenns erste Post evtl. unverständlich war). Es ist eine Frage der Philosophie. Je feiner und kleiner die zu testende Unit ist, desto leichter findet man Fehler, desto höher ist der Testabdeckungsgrad (alles positiv). Aber: Desto höher ist der Aufwand, desto höher ist der notwendige Umbau bei Umbau der zu testenden Klassen (alles negativ). Aber das sind gefühlte Faktoren, keine harten No-Gos. Wer sich en Aufwand machen will, wer sich (wie beim Zend Framework beispielsweise) eine 100% Code-Abdeckung in den Kopf gesetzt hat, der wird deutlich feiner aufgebaute Testfälle haben. Was man nie machen sollte: Das große Ganze zu vernachlässigen. Selbst wenn jede Methode für sich getestet wurde, sollte man immer auch noch Testfälle machen, die die gesamte Klasse testen. Man sollte Testfälle machen, die eine ganze Komponente, also mehrere Klassen testen. Aus zwei Gründen: Nach einem größeren Umbau hat man zumindest noch diese größeren Testfälle, die funktionieren müssen. Und zudem treten viele Fehler auch erst auf, wenn die Klassen miteinander agieren. Bei feinen Unit-Tests auf Methodenebene werden immer mal Konstellationen übersehen. Aber mal einen praktischen Nutzen davon: -> Gegeben sei eine abstrakte Datenbank-Basisklasese. Diese kann eine Entität aus einer Datenbanktabelle auslesen und in sie zurückschreiben. -> Um die ID eines Objektes rauszufinden interagiert diese Basisklasse relativ komplex mit der Persistenzschicht (Neues Objekt? Gelöschtes Objekt? usw.) Wenn man nun die Datenbankzugriffsklasse testet und eine andere Methode im Sinn hat, die lediglich die ID des Objektes abfragt um damit weiter zu hantieren, hat man die Wahl zwischen: a) Mocken der Persistenzschicht inklusive der 10 Aufrufe dahin. b) Mocken der Methode "GetID" um eine erwartete ID einfach direktzurückzugeben und damit die eigentliche Methode hantieren zu lassen. Dass GetID die richtige ID aus der Persistenzschicht abfragt, das wird von separaten Testfällen des Basisframeworks abgedeckt und ist dami nicht im Fokus der eigenen Testfälle. Ich hoffe, dass dieses Beispiel das Mocken von zumindest protected Methoden rechtfertigt. Im Extremfall auch das Mocken von Private-Methoden. __________________ www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih Geändert von mepeisen (15.04.2011 um 00:55 Uhr).

15.04.2011, 07:34
mr.luke Neuer Benutzer Registriert seit: 29.10.2008 Beiträge: 5 PHP-Kenntnisse: Fortgeschritten	Moin ... Moin ... Sorry, konnte mir bis jetzt noch nicht alle Antworten genau durchlesen. Deshalb nur eine kurze Antwort auf die Frage: Wie sind die anderen privaten / protected Methoden getestet? Natürlich gehe ich davon aus, dass diese getestet sind. Man sollte schliesslich auch für jede Methode eigene Unittests haben... ist dies nicht der Fall, so testet man über die parentMethod() die UnterMethoden, d.h. diese werden dann wahrscheinlich für sich selbst nicht eigenständig getestet. Für mich ein NoGo, denn was passiert, wenn die Methode z.B. bei unterschiedliche Results liefert und aus 7 unters. parentMethods() aufgerufen wird und sich entsprechend unterschiedlich verhält. Natürlich muss / sollte man dies refactorn, aber dies ist ein anderes Thema Fortsetzung folgt...