Arrivé à ce point, nous n'avons que deux tests pour le array de PHP et la fonction count(). Quand nous commencerons à tester les nombreuses fonctions array_*() que PHP offre, nous devrons écrire un test pour chacune d'elles. Nous pourrions écrire l'infrastructure pour tous ces tests à partir de zéro. Cependant, il est bien mieux d'écrire une infrastructure de tests une fois pour toute puis de n'écrire ensuite que les parties spécifiques à chaque test. PHPUnit est ce type d'infrastructure.

Un framework comme PHPUnit doit résoudre une série de contraintes, certaines d'entre elles semblant toujours contradictoires avec d'autres. Les tests doivent être à la fois :

Il existe deux antagonismes majeurs entre ces contraintes :

PHPUnit tente de résoudre ces conflits en utilisant PHP comme langage de test. Quelquefois, la pleine puissance de PHP est disproportionnée pour écrire de petits tests d'une ligne, mais en utilisant PHP, nous tirons profit de toute l'expérience et des outils dont disposent déjà les programmeurs. Puisque nous essayons de convaincre des testeurs réticents, limiter les obstacles pour écrire ces premiers tests est particulièrement important.

PHPUnit privilégie plutôt l'indépendance à la rapidité d'exécution. Les tests indépendants sont précieux car ils fournissent des retours de grande qualité. Vous n'obtenez pas un rapport avec un tas d'erreurs de test qui sont en fait provoqués par l'échec d'un test au début de la série et qui a laissé le monde en désordre pour les autres tests. Cette orientation en faveur des tests indépendants encourage les conceptions dotées d'un grand nombre d'objets simples. Chaque objet peut être testé rapidement de manière indépendante. Il en résulte de meilleures conceptions et des tests plus rapides.

PHPUnit part du postulat que la plupart des tests réussissent et qu'il n'est pas nécessaire de rendre compte des détails des tests réussis. Quand un test échoue, cela vaut la peine de le signaler et de détailler le problème. La grande majorité des tests doit réussir et aucun commentaire n'est intéressant si ce n'est le nombre de tests exécutés. Dans la pratique, ce postulat est implémenté dans les classes produisant les rapports et pas dans le noyau de PHPUnit. Quand les résultats d'une série de tests sont rapportés, vous voyez combien de tests ont été exécutés mais vous ne verrez les détails que pour ceux qui ont échoué.

Les tests sont supposés être à fine maille, ne testant qu'un seul aspect d'un seul objet. Par conséquent, la première fois qu'un test échoue, l'exécution du test s'interrompt et PHPUnit rapporte le problème. Tester en exécutant de nombreux petits tests est un art. Les tests à fine maille améliore la conception générale du système.

Lorsque vous testez un objet avec PHPUnit, vous ne le faites que via l'interface publique de l'objet. Tester en ne se basant que sur le comportement publiquement visible encourage à affronter et résoudre les problèmes de conception difficiles très tôt, avant que les conséquences d'une mauvaise conception ne puissent infecter de grandes parties du système.