2010-11-19 30 views
1

Je suis en train de développer un framework simple pour PHP qui gère et distribue les appels ajax. Une de ses caractéristiques est qu'il prend automatiquement soin d'envoyer les en-têtes appropriés en fonction de ce qui se passe dans le backend. Au cours des derniers jours, j'ai commencé à écrire beaucoup de tests unitaires pour PHPUnit et j'essaie d'obtenir un bon code coverage. (Oui, la couverture de code élevée par lui-même ne signifie pas vraiment quelque chose, je sais, mais c'est toujours un bon indicateur.)Couverture de code pour code non exécuté localement

Cependant, parce qu'il est (à ma connaissance) impossible d'envoyer/vérifier les en-têtes lorsque PHP est en mode CLI, beaucoup de tests doivent être effectués via un serveur web local. Cela me permet de vérifier facilement les en-têtes et le corps de la réponse. Malheureusement, le code exécuté lors de ces tests n'est, naturellement, pas suivi par PHPUnit. (Juste pour être clair: chaque morceau de code qui peut être vérifié localement, est vérifié localement, mais tout ce qui concerne les en-têtes ne tombe pas dans cette catégorie.)

Je sais que je peux encapsuler l'appel header() au cours d'essais avec un objet simulé. Cependant, alors je devrais ré-implémenter toute la logique du remplacement d'en-tête et pas avec tous ses caprices et bugs potentiels, donc je testerais essentiellement mon propre header() -implémentation au lieu de ce qui se passe vraiment - ce qui est précisément ce que I ne veulent pas veulent faire.

Donc, je suppose que ma question est la suivante: puis-je, d'une manière ou d'une autre, inclure ces "appels à distance" dans mon rapport de couverture de code? Ou dois-je (et c'est ma supposition) simplement accepter le fait que je dois manquer 100% de couverture de code afin de tester dans des conditions réelles?

Répondre

0

Apparemment, il n'y a pas moyen de le faire.

Alors que la réponse d'ircmaxell était intéressante, elle n'a pas vraiment répondu à ma question (d'où j'ai marqué cette réponse comme acceptée).

0

Eh bien, en pratique, il est pratiquement impossible d'obtenir une couverture de 100% pour une base de code entière. Là où vous voulez vraiment 100% est au cœur de l'application (les bibliothèques et les composants réutilisés). Le reste est très bon à tester, mais si vous trouvez qu'il y a des situations qui rendent le test assez difficile, ne vous insistez pas sur quelques lignes de code qui ne peuvent pas être testées.

En ce qui concerne votre problème spécifique, je n'écrirais même pas de tests unitaires pour ce genre de choses. Ce que je voudrais écrire sont des tests d'interface utilisateur utilisant Selenium HQ. Il est encore entièrement automatisé, et fonctionne depuis PHPUnit, mais il utilise un ou plusieurs navigateurs. Il est vraiment plus d'un test d'intégration ou de l'acceptation d'un test unitaire, mais cela fonctionne très bien ...

+0

J'ai de l'expérience avec le sélénium, et même si c'est un excellent outil, il ne s'applique vraiment pas ici. Peut-être que ce n'était pas clair de la façon dont j'ai décrit mon problème. – n3rd

+0

Eh bien, compte tenu de ces quelques références: [SO Question] (http://stackoverflow.com/questions/679218/best-way-to-inspect-http-response-headers-with-selenium), [Groupe Google] (http : //groups.google.com/group/selenium-users/browse_thread/thread/3e9e08000e58ccd1/1205af3c6b161cc4 PLI = 1) ... Mais si vous voulez essayer de décrire le problème d'une autre façon, je vais quand même essayer pour aider ... – ircmaxell

+0

Je ne suis pas avoir des problèmes d'accès ou de tester les en-têtes ou la réponse elle-même, j'utilise Zend_Http_Client pour cela. Je ne vois vraiment pas quel avantage supplémentaire Selenium a à offrir dans ce cas particulier. – n3rd