Comment citer un travail avec PHPUnit?

Je fais de la programmation de sites Web depuis 15 ans et PHP depuis environ 5 ans. J'ai toujours écrit du code solide. CEPENDANT, j'ai un client qui insiste pour que 80% du code soit testé à l'unité. Étant donné que le client est TOUJOURS DROIT, je prévois d'utiliser PHP_CodeSniffer pour m'assurer que mon code semble correct et PHPUnit pour faire mes tests unitaires. J'espère apprendre quelque chose à travers cette expérience.

S'agit-il des bons outils à utiliser? Combien de temps faut-il pour configurer PHPUnit et écrire le code supplémentaire? Cela devrait me prendre environ 8 semaines pour écrire les pages Web et l'auto-test comme je l'ai fait dans le passé. Si j'ajoute 4 jours supplémentaires (10%) pour les tests unitaires (PHPUnit), est-ce suffisant? Pensées? Suggestions? Merci.

En une seule ligne: cela dépend de la façon dont vous travaillez. Je pense que 10% est beaucoup trop peu. Elle devrait être d'au moins 25%, sinon 40%, sinon 60%, sinon plus.

Tout d'abord, je suis tout à fait d'accord avec votre client là-bas. Les tests unitaires sont une partie essentielle d'un produit robuste, facile à entretenir et à déboguer.

Je vais parler de ce que je sais. J'utilise TDD (Test-Driven Development) pour la plupart des projets. TDD vous fait essentiellement écrire les tests avant le code réel. Ils établissent un ensemble de critères d'acceptation auxquels le produit final doit répondre. Habituellement, vous passerez de 50% à 70% de votre temps à écrire des tests, et le reste à implémenter du code pour les faire passer.

Bien que cela puisse sembler absurde et / ou énorme, je peux vous assurer que ce n'est pas le cas. Voici pourquoi:

• Vous pourrez déterminer quels sont les meilleurs modèles architecturaux à utiliser lors de la rédaction des tests. De cette façon, lorsque vous commencez à coder, l'architecture de l'application ne changera que très peu (car nous savons tous combien il est coûteux de refaire une architecture d'application).
• Vous codez uniquement pour réussir les tests (ce qui rend le produit final acceptable). Vous ne passerez pas de temps à programmer des fonctionnalités inutiles / hors de portée.
• En ayant moins de code (c'est-à-dire: uniquement le code dont vous avez réellement besoin), il est moins sujet aux erreurs. (Moins de code = moins d'erreurs).
• Si vous faites une erreur, et vous le ferez, il vous faudra beaucoup moins de temps pour comprendre pourquoi il y a un problème et où il se trouve. Si les tests sont écrits correctement, cela signifie qu'une seule erreur entraînera une seule défaillance, pas une réaction en chaîne. De cette façon, vous pouvez facilement identifier la source du problème en quelques minutes, voire quelques secondes.
• Il faudra beaucoup moins de temps pour implémenter le code réel avec des tests unitaires. Dès qu'un test échoue, vous savez que quelque chose ne va pas. Vous n'avez pas à faire des allers-retours avec le client pour corriger les bogues.
• Vous devrez éventuellement faire des allers-retours avec le client pour corriger les bugs, car rien ne peut attraper 100% des erreurs. Cependant, vous pouvez facilement attraper 95% sinon plus.

PHPUnit est à peu près l'outil de facto pour les tests unitaires de PHP, et il est très bon dans ce domaine. Je n'ai pas beaucoup utilisé PHP_CodeSniffer. Cependant, je pense que si vous travaillez seul, vous n'en avez probablement pas besoin. Il est plus utile dans une équipe de s'assurer que le code a la même apparence, peu importe qui l'a codé.

Props à vous d'avoir l'attitude que vous apprendrez quelque chose de cette expérience. J'en suis sûr.

La toute première chose que vous devez apprendre est que la nécessité des tests unitaires n'a rien à voir avec votre expérience . Le meilleur développeur va également être l'un des meilleurs testeurs d'unités:

Bill Venners: Vous dites dans votre livre Refactoring: "Si vous voulez refactoriser, la condition préalable essentielle est d'avoir des tests solides." Cela signifie-t-il que si vous n'avez pas de tests, vous ne devriez pas refactoriser?

Martin Fowler: Vous devriez penser à cela comme marcher sur une corde raide sans filet. Si vous êtes doué pour marcher sur une corde raide et que ce n'est pas si haut, alors vous pourriez l'essayer. Mais si vous n'avez jamais marché sur une corde raide auparavant et que c'est au-dessus des chutes du Niagara, vous voulez probablement un bon filet.

^{Sur http://www.artima.com/intv/refactorP.html}

J'avais l'habitude d'écrire PHP sans test unitaire. Puis, après des années de pratique des tests unitaires en Java, j'ai constaté que je ne pouvais pas travailler sur quelque chose de beaucoup plus compliqué que des pages simples en PHP sans tests unitaires. La raison? Productivité . Sans tests unitaires, je ne pouvais pas refaçonner avec confiance - cela signifiait que soit A) je devrais démolir beaucoup plus et travailler sur tout depuis le début, ou B) , je devrais faire face à un code laid et hérité.

Lorsque vous faites une offre, devez-vous prendre en compte le temps de test? Oui . Semble-t-il intuitif que cela prendra plus de temps? Oui encore . Vous aurez probablement, comme certaines autres réponses l'ont approximativement estimé, besoin d'estimer 50 à 100% de plus que sans tests unitaires.

Toutefois!...

• Vous détecterez et corrigerez les trous de spécification plus tôt
• Ce qui signifie que vous développerez une spécification plus propre et plus solide
• Vous serez en mesure de répondre rapidement et en toute confiance aux changements de spécifications
• Vous aurez moins de bugs
• Vos bugs seront détectés plus tôt et plus faciles à corriger

Et par conséquent, vos estimations seront plus précises . Si vous facturez toutes les heures, vous impressionnerez davantage vos clients et pourrez augmenter vos tarifs. Si vous facturez forfaitaire, vous gagnerez plus d'argent par heure.

Sans test, vos estimations sont probablement un crapshoot. Les bogues, les modifications et les redéfinitions sont tous terribles pour une estimation précise. Les tests sont la clé pour minimiser l'impact des trois!

Il n'y a pas de réponse simple quant au temps que cela vous prendra.

Mais en règle générale, si c'est un projet court: je dirais que le développement associé à de bons tests unitaires prendra 1,75 à 2 fois plus de temps que le développement sans tests unitaires. Pour les projets plus longs, peut-être 25-30%?

Je suggère de faire des tests unitaires avant d'écrire votre code. Pris de cette façon, la construction de l'échafaudage de test unitaire devient en fait une partie de votre processus de conception, et vous ne devez donc pas considérer que vous perdez du temps à effectuer des tests unitaires, mais plutôt que la construction du test unitaire vous aide à concevoir un excellent produit et l'existence de ce test une fois que vous l'avez construit vous permet de vous assurer qu'il reste ainsi. Devoir d'abord écrire des tests unitaires est merveilleux car il permet de se concentrer sur les besoins réels, nous donne un moyen clair de tester si nous avons terminé (passer des tests unitaires) et nous aide à «tester tôt et tester souvent».

Quant à PHPUnit .... Cela fait un moment que je ne l'ai pas utilisé, j'ai l'impression qu'il est puissant mais a peut-être besoin de plus de travail avant d'être vraiment poli.

S'il y a une chose que je veux communiquer ici, cependant: veuillez ne pas voir les tests unitaires comme une simple formalité à la fin de votre projet. Si c'est tout, à mon avis, cela ne vaut rien.

Jusqu'à présent, les réponses sont assez approfondies, je vais donc ajouter un point non couvert: le temps supplémentaire dû à l'utilisation de PHPUnit sera

1. plus haut au début puisque vous l'apprenez, et
2. réduisez le temps de développement sans test lorsque vous gagnez en confiance.

Les classes de modèle de test unitaire qui ne traitent pas de la présentation sont assez simples. Vous écrivez un test pour chaque classe, et dans ces cas de test, vous pouvez directement instancier et configurer un objet pour tester une méthode / fonctionnalité particulière. Une fois que vous aurez configuré et exécuté PHPUnit, vous pourrez faire fonctionner ces tests rapidement.

Les pages Web de test unitaire peuvent être plus délicates. Si vous utilisez Zend Framework, Symfony, Smarty ou tout autre moteur MVC, faire fonctionner PHPUnit avec eux peut prendre plus de temps. Nous utilisons Zend Framework et j'ai passé beaucoup de temps à créer des classes de base pour tester les contrôleurs et afficher les scripts de manière isolée. Compte tenu de la taille de ce projet, vous feriez probablement mieux de commencer par ControllerTestCase.