PHPUnit Formular testen

Rastaloeckchen · 22.07.2009, 20:57

nAbend zusammen,

ich möchte mir gerne eine "kleine" Formular Klasse schreiben, rein zu Übungszwecken.

Dabei möchte ich dem First Test Ansatz folgen.

Von PHPUunit hatte ich bis vor 2 Tagen noch überhaupt kein Plan, und heute sieht es nicht besser aus

.

Hier mal meine kleine Formular Klasse :

PHP-Code:

  class Formular {

    

    public $formularElements = array ();

    

    public function addField($formularElement) {

        

        if (!$formularElement instanceof TextField ) {

        

            return false;

        

        } 

        

        if ($formularElement->name == "") {

            

            $element = get_class($formularElement);

            throw new Exception("Name von $element nicht gesetzt ");

            

        }

        

            if (!$formularElement ) {

        

            throw new Exception("Kein Element übergeben");

        

        } 

 
    

             $this->formularElements [$formularElement->name] = $formularElement;

        

        return true;

        

       }

 
}

Ich teste mit PHPUnit :

PHP-Code:

   
class FormularTest extends PHPUnit_Framework_TestCase {

    

    

    protected function setUp() {

        

        parent::setUp ();

        

        $this->Formular = new Formular();

        $this->TextField = new TextField('test');

        

        

    

    }

 
    public function testAddField() {

    

                // Teste hier ob true oder false zurückgegeben wird

 
        $this->assertTrue($this->Formular->addField($this->TextField));

    

    }

 
 
}

So nun meine Frage. Ist das bis jetzt schon alles Schwachsinn oder bin ich auf dem richtigen Weg?

Mehr zu testen gibt es in dem Falls ja nicht oder. Habe ich überhaupt verstanden worumes geht ?

Gruß Rasta

Chriz · 22.07.2009, 21:28

Hallo!

Zitat:

Dabei möchte ich dem First Test Ansatz folgen.

Tust du nicht, die Formular-Klasse gibt es ja bereits.

Zunaechst mal solltest du alle Methoden und Parameter der Klasse definieren, von mir aus kannst du also bereits ein Interface fuer die Formular-Klasse schreiben:
PHP: Object Interfaces - Manual

Abgesehen davon ist deine Implementierung bereits zweifelhaft. Ob er Name des Elementes leer ist, hat zunaechst mal die TextField-Klasse selbst zu ueberpruefen, nicht das Formular (abgesehen davon waere ein Leerzeichen ein gueltiger Name, was nicht der Fall ist). Anschliessend kann das Formular den Namen erneut gegenpruefen, um z.B. doppelte Elementnamen abzulehnen. Ich finde es auch nicht gut, dass du mal FALSE zurueckwirfst, mal eine Exception verwendest. Die Uebergabe eines fehlerhaften Textfeldes ist in meinen Augen immer eine Ausnahme, im Normalfall sollte ein Formular fehlerfrei erzeugt werden! Abgesehen davon gibt es bereits Typehints, d.h. dein Test auf instanceof ist unnoetig und unperformant:
PHP: Type Hinting - Manual

Zu Unittests kann man eine ganze Menge schreiben, wichtig ist, dass du die Grenzfaelle erkennst und entsprechend kombiniert aufstellst, z.B. mit einem orthogonalen Array, das wird vermutlich aber erst wichtig, wenn du Validatoren und Filter in deine Formular-Klasse integrierst.

PS: addTextField() ist eine Setter-Methode, ein Rueckgabewert fuer Setter-Methoden ist nicht ueblich!

nikosch · 22.07.2009, 21:34

Zitat:

Ob er Name des Elementes leer ist, hat zunaechst mal die TextField-Klasse selbst zu ueberpruefen, nicht das Formular

Naja, nach dem Ansatz der Zusicherungen/Design by Contract ist es weder Aufgabe der Form- noch der Elementklasse, sondern des Kontextes, der das Formelement erzeugt.

Chriz · 22.07.2009, 22:25

Nein, du ueberpruefst ja nicht Variablen im freien Fluss, zumindest selten, sondern direkt hinter den Schnittstellen! Sonst muesste ja vor jedem Aufruf eine Zusicherung stehen, bei mehrfachem Aufruf ja auch die Zusicherung mehrfach. Das ist unhandlich. Da prueft man doch lieber dort, wo letztlich eh alles landet, direkt am Anfang einer Methode/Funktion. Es gibt ja nach DbC folgende "Pruefkategorien":
Vor-Bedingung (valide Eingabewerte sicherstellen)
Nach-Bedingung (valide Ausgabewert sicherstellen)
Invarianz (Zwischenwerte pruefen - z.B. vor einer Division den Nenner != 0 testen)
Schleifeninvarianz (Schleifenabbruchbedingung sicherstellen)

Invarianz wird soweit ich weiss relativ selten verwendet, sonst koennte man schliesslich alles testen. Abgesehen davon ist ja DbC hier erstmal garnicht gefragt, weil das ja mehr ein Unittest in der Klasse selbst ist. DbC wuerde ich bei Unittests erstmal ausklammern (assert_options(ASSERT_ACTIVE, 0), wenn assert() nun nur String-Ausdruecke uebergeben wurden, drueckt das nichtmal sonderlich auf die Performance), im Produktivbetrieb wird sowieso eher auf Defensive-Design gesetzt (Fehler nicht erkennen, sondern korrigieren, z.B. bei ungueltigem Feldnamen einfach einen automatischen gueltigen zuordnen, ob das spaeter nicht andere Fehler provoziert sei mal dahingestellt).

Insofern sollte man den Test also dort ansetzen, wo er (aus Sicht der Klasse) entsteht (setter), oder dort wo er zuerst Probleme bereitet (getter).

nikosch · 22.07.2009, 22:37

Sicher, das ist hier nicht das Thema. Deshalb

[OT]

Zitat:

Sonst muesste ja vor jedem Aufruf eine Zusicherung stehen, bei mehrfachem Aufruf ja auch die Zusicherung mehrfach.

Genauso ist das. Dann ist wohl anzustreben, Implementierungen zentral zu gestalten, erfolgte Validierungen/Typprüfungen zu cachen etc.

Zitat:

Das ist unhandlich. Da prueft man doch lieber dort, wo letztlich eh alles landet, direkt am Anfang einer Methode/Funktion.

Darum gehts aber nicht. Genau wie Patterns geht es um das Prinzip. Es reduziert das Objekt auf seine Funktionalität. Ob der Code aussen oder innen steht ist an sich irrelevant, vom DRY mal angesehen. Auf der Gegenseite würde die Prüfung im Objekt ja auch jedesmal ausgeführt, selbst wenn man jedesmal brav den korrekten Datentyp übergibt. Bei Daten, die ein Objekt immer wieder on the fly erzeugt, potenziert sich die Problematik noch: Selbst zum 100sten mal mit denselben Daten aufgerufen, würde die Methode wieder und wieder die Parameter prüfen.

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
PHP: Formular Generator	Zergling-new	Tutorials	16	06.07.2010 03:14
[Erledigt] Kontaktformular bitte mal im FF, IE und Opera testen	litterauspirna	Off-Topic Diskussionen	5	13.06.2009 19:52
PDF Formular ausfüllen mit PHP Formular	oomworld	PHP Tipps 2009	1	26.03.2009 19:09
Wie würdet ihr das Formular submitten?	pras	Datenbanken	5	05.03.2009 21:33
[Erledigt] Formular auf Inhalt prüfen Formular auf Inhalt prüfen und Abfrage an MySQL	halekin	PHP Tipps 2009	3	13.01.2009 21:17
Problem mit Formular, Daten an datenbank senden	Aurec	PHP Tipps 2008	11	20.11.2008 18:17
Wert aus Textfeld in neues Formular übernehmen (kein Submit)	PsychoEagle	HTML, Usability und Barrierefreiheit	9	02.01.2007 14:51
formular includen	samspa5	PHP Tipps 2006	13	18.03.2006 11:37
[Erledigt] Formular in Formular		HTML, Usability und Barrierefreiheit	4	19.10.2005 12:18
[Erledigt] Formular testen ....		HTML, Usability und Barrierefreiheit	7	19.09.2005 14:03
[Erledigt] PHP Formular ~~wichtig~~		PHP Tipps 2005	27	29.05.2005 19:38
[Erledigt] Im Formular user abfragen?		Datenbanken	3	06.01.2005 10:51
[Erledigt] Daten in einem Formular ausgeben und ändern		PHP Tipps 2004-2	7	07.12.2004 17:22
Brauche PHP Formular		Beitragsarchiv	9	16.08.2004 16:23
[Erledigt] Daten in neuem Formular anzeigen		PHP Tipps 2004	6	21.07.2004 10:44

22.07.2009, 20:57
Rastaloeckchen Benutzer Registriert seit: 08.03.2009 Beiträge: 50 PHP-Kenntnisse: Anfänger	PHPUnit Formular testen nAbend zusammen, ich möchte mir gerne eine "kleine" Formular Klasse schreiben, rein zu Übungszwecken. Dabei möchte ich dem First Test Ansatz folgen. Von PHPUunit hatte ich bis vor 2 Tagen noch überhaupt kein Plan, und heute sieht es nicht besser aus . Hier mal meine kleine Formular Klasse : PHP-Code: class Formular { public $formularElements = array (); public function addField($formularElement) { if (!$formularElement instanceof TextField ) { return false; } if ($formularElement->name == "") { $element = get_class($formularElement); throw new Exception("Name von $element nicht gesetzt "); } if (!$formularElement ) { throw new Exception("Kein Element übergeben"); } $this->formularElements [$formularElement->name] = $formularElement; return true; } } Ich teste mit PHPUnit : PHP-Code: class FormularTest extends PHPUnit_Framework_TestCase { protected function setUp() { parent::setUp (); $this->Formular = new Formular(); $this->TextField = new TextField('test'); } public function testAddField() { // Teste hier ob true oder false zurückgegeben wird $this->assertTrue($this->Formular->addField($this->TextField)); } } So nun meine Frage. Ist das bis jetzt schon alles Schwachsinn oder bin ich auf dem richtigen Weg? Mehr zu testen gibt es in dem Falls ja nicht oder. Habe ich überhaupt verstanden worumes geht ? Gruß Rasta


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

22.07.2009, 22:25
Chriz Moderator Registriert seit: 11.05.2008 Beiträge: 6.069	Nein, du ueberpruefst ja nicht Variablen im freien Fluss, zumindest selten, sondern direkt hinter den Schnittstellen! Sonst muesste ja vor jedem Aufruf eine Zusicherung stehen, bei mehrfachem Aufruf ja auch die Zusicherung mehrfach. Das ist unhandlich. Da prueft man doch lieber dort, wo letztlich eh alles landet, direkt am Anfang einer Methode/Funktion. Es gibt ja nach DbC folgende "Pruefkategorien": Vor-Bedingung (valide Eingabewerte sicherstellen) Nach-Bedingung (valide Ausgabewert sicherstellen) Invarianz (Zwischenwerte pruefen - z.B. vor einer Division den Nenner != 0 testen) Schleifeninvarianz (Schleifenabbruchbedingung sicherstellen) Invarianz wird soweit ich weiss relativ selten verwendet, sonst koennte man schliesslich alles testen. Abgesehen davon ist ja DbC hier erstmal garnicht gefragt, weil das ja mehr ein Unittest in der Klasse selbst ist. DbC wuerde ich bei Unittests erstmal ausklammern (assert_options(ASSERT_ACTIVE, 0), wenn assert() nun nur String-Ausdruecke uebergeben wurden, drueckt das nichtmal sonderlich auf die Performance), im Produktivbetrieb wird sowieso eher auf Defensive-Design gesetzt (Fehler nicht erkennen, sondern korrigieren, z.B. bei ungueltigem Feldnamen einfach einen automatischen gueltigen zuordnen, ob das spaeter nicht andere Fehler provoziert sei mal dahingestellt). Insofern sollte man den Test also dort ansetzen, wo er (aus Sicht der Klasse) entsteht (setter), oder dort wo er zuerst Probleme bereitet (getter). __________________ "Nuschel ich?" - "Was?"