PHP Sammelthread: Zend Framework und alles was dazugehört

Aber dann kann ich ja nie jede Methode einzeln testen, sondern im Prinzip immer nur das Zusammenspiel aller:(
 
Aber dann kann ich ja nie jede Methode einzeln testen, sondern im Prinzip immer nur das Zusammenspiel aller:(

Ist es möglich die Standhaftigkeit einer Mauer zu prüfen, ohne dass sie gebaut wurde?
(Anmerkung: keine Simulationen, ich rede von einer echten Mauer :biggrin:)


Das klingt schlimmer als es wirklich ist ;)
Ich habe auch schon ganze Komponenten mit dem Muster an UnitTests gebaut und bei der Optimierung, dann etwas kaputt gemacht, der Fehler war aber immer leicht behoben, obwohl auf einmal 64 Tests kaputt waren :biggrin:

Man sollte bei fehlschlagenden Tests eben immer erst die simplesten korrigieren, also ein "insertIncreasesHeightTest" vor dem "treeIsAlwaysBalancedTest" (AVL-Bäume).
 
Also ist es gar nicht Ziel eines Unit-Tests jede Methode einzeln zu testen, sondern die Klasse als ganzes?
Das macht das ganze irgendwie leichter:biggrin:
 
Das würde ich so nicht ausdrücken.
Es geht darum das Verhalten der Klasse zu testen ;)

Also auf deinen Baum bezogen:
  • Eigenschaften eines leeren Baumes stimmen
  • Hinzufügen von Knoten funktioniert
  • hinzugefügt Knoten haben die Richtige Höhe
  • es kann immer nur ein Knoten links bzw. rechts sein
  • löschen von Knoten löscht diese wirklich
  • löschen eines nicht vorhandenen Knoten produziert Fehler
  • usw
Da hast du dann eben Tests die nur 1-2 Methoden nutzen (primitive Tests) und Testfälle die auf mehreren Operationen basieren.


nebenbei bemerkt müsste die insert-Methode 2 Parameter haben oder ein Array/Objekt als Parameter haben.
 

Okay, das macht die Sache einfach.
Unser Lehrer wollte nur ursprünglich die Arbeit mittels diesen Unit-Tests beurteilen. insert()-Methode falsch und 4 Tests schlagen fehl:ugly:

nebenbei bemerkt müsste die insert-Methode 2 Parameter haben oder ein Array/Objekt als Parameter haben.

War zwar nur ein Beispiel, aber: Was willst du denn noch dazu speichern?
In meinem Beispiel gings um nen binären Suchbaum, bei dem nur der Key gespeichert wird.
 
(sry für den neuen Post, aber in den alten passt es nicht wirklich sinnvoll rein)

Ich habe z.B. mal testweise für das ZendFramework einen Compiler geschrieben, der mehrere gewünschte Klassen in eine Datei "kompiliert".
Dabei muss natürlich erst der Sourcecode geparst werden (Tokenizer), dann müssen Abhängigkeiten erkannt werden (Class extends, implements), am Schluss die Menge der Klassen sinnvoll geordnet werden, so dass sie kompilierbar sind (topologische Sortierung: erst die abstrakte Klasse, dann die extendende).

Hier mal ein Beispiel einer der Subkomponenten, ein Detector der Abhängigkeiten in dem zerlegten Quellcode findet:

Klasse: Zfast_Compiler_Detector_Oop
Testcase: Zfast_Compiler_Detector_OopTest
 
Okay, das macht die Sache einfach.
Unser Lehrer wollte nur ursprünglich die Arbeit mittels diesen Unit-Tests beurteilen. insert()-Methode falsch und 4 Tests schlagen fehl:ugly:
im Prinzip hat er damit doch auch recht, wenn die insert-Methode defekt ist, ist auch der ganze Rest kaputt, da fast alles darauf aufbaut.

War zwar nur ein Beispiel, aber: Was willst du denn noch dazu speichern?
In meinem Beispiel gings um nen binären Suchbaum, bei dem nur der Key gespeichert wird.
Wenn du die Klasse Tree nennst, ist es ein allgemeiner Baum und man muss diesen modifizieren können: links/rechts Knoten einfügen können usw.

Also brauchst du eigentlich die Implementation eines allgemeinen Baumes, und eine Klasse die intern den Baum nutzt, nach außen aber nur als Klasse fungierte um Daten zu speichern, finden und zu löschen (analog zu der Collection-API in Java, also dem List-Interface mit seinen vielen Ausprägungen)
 
begrüße!

ich habe mal wieder ein konzeptionelles problem.. diesmal geht es um acl ;)

ich hatte es vor einiger zeit schonmal hier angesprochen.. bei mir im system gibt es ziemlich viele rollen (am ende wahrscheinlich um die 40 oder eventuell sogar mehr.. daran kann ich auch nichts ändern)

die benutzer können mehrere rollen haben.. die rechte sollen hierbei einfach "addiert" werden..
einfaches beispiel:
Rolle "A" darf X und Y
Rolle "B" darf Z

der benutzer hat die rolle A und B, die rechte werden also addiert.. also darf der benutzer X, Y, Z

mit Zend_Acl könnte man das relativ einfach umsetzen, indem ich den benutzer "user_(ID)" als neue rolle anlege und "A" und "B" als parents dafür eintrage.. also:
PHP:
$acl->addRole("user_(ID)", array('A', 'B'));

ich habe aber angst, dass das ganze dann ziemlich aufgebläht und dadurch eventuell unperformant wird.. das acl objekt im cache bestünde dann fix aus den ~40 rollen und zusätzlich noch jeweils eine rolle für jeden eingeloggten benutzer..

denkt ihr das ist praktikabel? oder meint ihr es wäre sinnvoller ein acl objekt für die fixen rollen und dann jeweils acl objekte für die einzelnen aktiven benutzer zu erstellen? dann könnte man benutzer acl's getrennt cachen und hätte nicht mehr so ne große datenmenge auf einmal..
 
Hmmm.. irgendwo hatte ich mal in einem Tutorial gelesen, dass es ja reicht wenn man nur benötigte Rollen dem ACL-Objekt hinzufügt. Wäre das nicht was? ;) (Und dann für jeden User evntl. das Objekt cachen..)
 
In die Richtung dachte ich auch gerade.

Die Rechte mit NestedSets in die DB schreiben, dann wenn sich ein User einloggt den Rechtebaum dazu auslesen, das ACL-Objekt erzeugen und in der Session speichern.
 
Ich bin immer noch am lesen:biggrin:

Sieht nach viel neuem Stoff aus, schon lang nicht mehr sowas gelesen, derweil tu ich das so gern:mrgreen:
 
Bin ich mal gespannt ob die das über so einen Broker lösen wollen wie es da gezeigt wird.

ehrlich gesagt mag ich den Ansatz nicht :biggrin:
Nachdem ich vor einiger Zeit endlich mal meine Smarty-Brücke über Bord geworfen habe, finde ich aktuell den View-Teil sehr genial, schön simpel ist das alles gelöst.
 
Nachdem ich vor einiger Zeit endlich mal meine Smarty-Brücke über Bord geworfen habe, finde ich aktuell den View-Teil sehr genial, schön simpel ist das alles gelöst.

Also ich habe mei meinem Smarty Viewhelper einfach $this als 'this' im Template deklariert und kann somit auch über (fast) alle ViewHelper zugreifen (paar machen nunmal Probleme bei den Argumenten die benötigt werden)
 
(paar machen nunmal Probleme bei den Argumenten die benötigt werden)
richtig, und gerade so Dinge wie der URL-Helper der Arrays als Input möchte, ist doch in Smarty nicht ordentlich umsetzbar.
Ich war bisher ein großer Verfechter von Smarty, aber mit Zend_View hat es für mich in ZF-Projekten ausgedient.
 
Ich denke, ich habe ein kleines Strukturproblem:(

Folgendes:
Im Moment habe ich einige Bootstrap Methoden, die ich bei einigen Seiten in meiner App nicht brauche. Da diese Seiten aber am meisten aufgerufen werden, will ich die natürlich da rausbringen, und nur laden, wenn die Site auch benötigt wird?

Mein Lösungsansatz wäre folgender:

  1. Plugin erstellen, dass diese Methoden bei dispatchLoopStartup beinhaltet
  2. Plugin im Bootstrap registrieren
  3. Im Plugin abfragen, ob der Request einer dieser Seiten anfordert. Wenn ja, Layout deaktivieren. Wenn nein, dann View, Cache, etc. initialisieren.
Andere/Bessere Ansätze, oder ist mein Ansatz so gut?