Yesterday I wrote about setting up a symfony plugin project in phpUnderControl. However so far I’ve been using Hudson as my Continuous Integration server. So before comparing the two I will explain how to achieve yesterdays setup using Hudson. (more…)

Clover · Continuous Integration · Hudson · Integrations Tests · phpUnit · Plugin · sfImageTransformExtraPlugin · symfony · Test Coverage · Tests · Unit Tests

As I’ve just started to look into phpUnderControl again I thought why not try to setup a project for testing sfImageTransformExtraPlugin running all the PHPUnit tests that I wrote about last week.

So the goal is to setup a phpuc project for a single plugin but with all dependencies (symfony itself) provided. This was a bit tricky so here we go! (more…)

Clover · Continuous Integration · CruiseControl · Integrations Tests · phpUnderControl · phpUnit · Plugin · sfImageTransformExtraPlugin · symfony · Test Coverage · Tests · Unit Tests

Ich denke immer noch über die Ausschlüsse aus meinem Code Coverage Report nach. Irgendwie bin ich nach wie vor nicht so richtig damit zufrieden.

Mit 3rd Party Tool meine ich in meinem Fall symfony, aber es könnte auch jedes andere Framwork sein oder sogar eine Software wie z.B. WordPress für die ich ein Plugin oder eine Erweiterung schreiben will. Es gilt auch z.B. für einen neuen Sniff, den ich für PHP_Codesniffer schreibe. Es geht also darum, dass ich Code schreibe, aber die Basis Software in der ich das tue nicht unter meiner Kontrolle steht.

Was will ich mit dem (Clover) Report überhaupt erreichen?

Ich will eine Übersicht und Statistik erhalten, die mich genauestens darüber informiert, welche Teile meines (!) Codes bereits mit Unit Tests versehen sind, und welche noch nicht, damit ich entsprechend Tests nachrüsten kann.

Von diesem Report ausschliessen kann ich lediglich Code, der nicht getestet werden muss/kann. Aber wie sind die Kriterien, dies herauszufinden? Ein paar hatte ich ja schon:

• Eingesetzte Software Komponenten, die nicht unter der eigenen (Versions-) Kontrolle stehen, müssen nicht von eigenen Tests abgedeckt sein
• Tests müssen nicht nochmal getestet werden (müssen aber natürlich trotzdem gewissenhaft geschrieben und gepflegt werden)
• View Templates, in denen ich lediglich Variablen ausgebe (so sollte es sein), denn die können in der Regel nicht instanziert werden
• Controller Code, denn dieser ist besser mit Functional Tests abgedeckt
• Generierter Code, der ohne das Framework nicht läuft

Aber habe ich damit Recht?

(more…)

Clover · Konfiguration · phpUnit · Test Coverage · Tests · Unit Tests

Meinen Code Coverage / Testabdeckungsreport von gestern möchte ich heute in meine Hudson Installation integrieren. Das macht Sinn, da ich hier als Entwickler immer als erstes drauf hingewiesen werde, wenn was fehlgeschlagen ist. Ich komme also eh öfters hierher und kann so quasi nebenbei einen Eindruck über meine eigene Abdeckung erhalten.

Zunächst will ich das Thema der Begrenzung nochmal aufgreifen, denn so hunderprozentig zufrieden bin ich noch nicht. Denn wie ich im letzten Screenshot gestern gezeigt hatte, werden für den Coverage Report nach wie vor Dateien berücksichtigt, die sich nicht innerhalb meines Plugins befinden. Die müssen natürlich auch getestet werden, aber wohl kaum mit Tests, die sich in meinem Plugin befinden.

Was ich will ist sowas wie das hier:

PHPUnit Code Coverage Report für ein symfony Plugin

Ich will also mit Tests, die sich innerhalb meines Plugins befinden ausschliesslich Code testen, der sich ebenfalls dort befindet.

Stellt sich also zunächst die Frage: wie mache ich das? Und gleich anschliessend: Muss ich immer noch was ausschliessen?

Die erste Frage beantwortet sich leicht. Hier meine phpunit.xml.

(more…)

Clover · Continuous Integration · Hudson · Konfiguration · phpUnit · Test Coverage · Tests · Unit Tests