Als je classes gaat schrijven dan heb je de mogelijkheid om statische methodes te definiëren. Je hoeft dan geen instantie te maken, maar je kunt gelijk de methode uitvoeren. Ideaal, zou je denken.

Er zijn situaties waarbij ik het gebruik van statische methodes toejuich. Het is bijvoorbeeld geschikt om helpers mee te maken. Daarnaast kun je allerlei factory methodes maken, (dit bij gebrek aan method overloading in php).

Statische methodes zijn zó toegankelijk, dat het ook weer een val op zich kan vormen. Dit is vooral het geval als ze onderlinge afhankelijkheden hebben. Het probleem uit zich dan tijdens het schrijven van de unit tests.

Unit tests en mocks

Bij het schrijven van unit tests kijk je of elk stukje code (unit) goed functioneert. In de meeste gevallen test je per methode. Soms heeft de ene methode een dependency naar de andere. Je wilt dan methode x testen en methode y, maar niet gezamenlijk.

Hiervoor kan je mocks gebruiken, daarbij overschrijf je bepaalde functies. Deze specificeer je zelf. Als je methode x aan het testen bent, dan kun je dus veinzen dat methode y een bepaalde waarde teruggeeft.

Static = static

Het probleem is dat static eigenlijk gewoon static is en dus overal kan leven. Het is immers niet toegankelijk. Een eenvoudige string manipulatie of bewerking op een array is nog te doen, maar als statische methodes afhankelijkheden hebben op andere methodes, dan wordt het lastig.

Als je in unit testing met bijvoorbeeld Mockery statische methodes gaat mocken, dan leeft dit overal (want static). Dit is dus niet wenselijk.

Oplossing?

De oplossing is geen static methodes gebruiken of geen unit tests schrijven. Dat laatste is nogal rigide. Dus ik zou aanbevelen om alleen datgene te testen wat te doen is en in het achterhoofd houden dat statische methodes lastig te testen zijn.

Andere oplossing is test driven development. Op dat moment weet je waarschijnlijk niet direct dat je oplossing een statische methode zal zijn, dus hiermee kun je het probleem voorkomen.