Imagine you’re a business owner. You know what you want to get developed, you have the budget for it and you know when you need to see a result. You have someone to manage your development team (call him the product owner if you like) and the team seems skilled.

Now what do you need unit tests for?

(more…)

Test Coverage · Test Driven Development · Unit Tests

I’m not sure if it’s a recent development or if it was only me noticing late but nowadays more and more developers talk and actually care about topics like writing tests, software metrics, coding conventions, decoupled-ness, modularity and even formerly dead-boring documentation.

And when working on some private projects or contributing to Open Source software some of these developers actually try to apply all these things and attempt to write good and clean software. Often with quite impressive results.

But when it comes to real life clients projects that you actually get paid for a lot of these intentions vanish. Reason: The client wouldn’t pay for it.

(more…)

Code Quality · Documentation · Estimates · Project management · Test Coverage · Unit Tests

Yesterday I wrote a lot of functional tests for a symfony plugin that provides and XML web service interface.

Using symfonys functional testing classes this is actually quite easy to do.

But wouldn’t it be cool if you could integrate these tests into your continuous integration service just like PHPUnit tests? Wouldn’t it be cool to be able to generate PHPUnit coverage reports?

(more…)

Continuous Integration · Functional Tests · lime · phpUnit · plugins · Refactoring · symfony · Test Coverage

As I mentioned before I am working on a small framework to implement custom stream wrappers.

For example you can later use this to easily wrap access to a web service or similar.

As of today I reached a 90+% code coverage and everything passes. Check out the sources and see if some test does not work for you.

(more…)

PHP · phpUnit · Stream Wrapper · Stream Wrappers · StreamHitching · Streams · Test Coverage · Unit Tests

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

Mein sfImageTransformExtraPlugin nähert sich langsam aber sicher dem ersten Stable Release mit der Nummer 1.0.0.

So kurz vor dem Ziel ist eine komische Zeit, denn man weiss ja, dass ein solches Release kein Ende der Entwicklung darstellt, sondern lediglich einen weiteren Milestone.

Was von den vielen offenen Todos gilt es denn nun wirklich noch unbedingt vorher abzuarbeiten und was kann auch in einem späteren Minor Release folgen?

Was sind die Anforderungen eines Major Releases und wie erkenne ich, welches Todo notwendig und welches optional ist?

(more…)

Functional Tests · Refactoring · Release Management · sfImageTransformExtraPlugin · symfony · Test Coverage · Unit Tests

Vor ein paar Tagen hat Bernhard in seinem Blog einen weiteren sehr anschaulichen Artikel zum Thema Testabdeckung geschrieben. Er liefert darin eine schlüssige Begründung warum eine hundertprozentige Testabdeckung nicht erstrebenswert sein soll.

Ich hab mir da nun auch nochmal ein paar Gedanken zu gemacht und denke Gründe für eine Abweichung gefunden zu haben.

(more…)

Bernhard Schussek · Test Coverage

Gestern wurde ich von einem Kollegen (danke Nils) auf das Blog whitewashing von Benjamin Eberlei aufmerksam gemacht. Benjamin ist ein aktiver Contributer verschiedener Open Source Projekte und hat viele interessante Posts geschrieben.

An einem Beitrag bin ich etwas hängengeblieben. Er hat auf der IPCSpring im letzten Jahr einen Vortag über Frameworks und ihren Umgang mit Tests gehalten. Man muss ein wenig googlen, um seine Slides zu finden, aber zu finden sind sie schliesslich auf Slideshare.

Benjamin stellt das Zend Framwork, symfony, ezComponents und CakePHP gegenüber und beurteilt recht objektiv folgende Kriterien:

• Einstellung des jeweiligen Projektes zum Thema Tests
• Anzahl der vorhandenen Unit Tests
• Eingesetztes Testing Framework
• Code Coverage
• Code Duplication

Seine Ergebnisse sind nicht besonders überraschend. Oder doch?

(more…)

Benjamin Eberlei · Frameworks · lime · phpUnit · symfony · Test Coverage

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