Je suis à la recherche d'un tutoriel qui explique pourquoi et comment comment écrire des tests unitaires utiles. Plus précisément, je suis intéressé par PHPUnit, mais plus général pourrait être un bon pour expliquer cela. S'il vous plaît noter que Je ne cherche pas d'informations techniques sur la façon d'utiliser PHPunit - plutôt le tutoriel sur la façon de penser!Tutoriel PHPUnit? Ou plus général - tutoriel de test d'unité vaut la peine de recommander?
Je ne connais pas de tutoriel. Mais je peux vous donner mon point de vue à partir de ce que j'ai recueilli au fil des années.
L'écriture des UnitTests vise à tester la fonctionnalité de l'application. Donc, étant donné que vous dites que vous écrivez une classe de base qui a 3 fonctions, getData setData et displaydata (juste en pensant au dessus de ma tête). Vous voulez écrire un cas d'unité qui va dans un ensemble de données (vous passez de bonnes données et de mauvaises données car il est important de savoir qu'il commet des erreurs correctement). Ensuite, vous vérifiez le setData, soit via un appel DB ou avec la même classe en utilisant le getData, et vous essayez d'obtenir les données avec de mauvaises données, de bonnes données, etc. Assurez-vous que cela gère correctement. Ensuite, vous écrivez les données d'affichage et rincez et répétez.
Fondamentalement, vous voulez tester que la classe de base (ou classes d'application) gère correctement les données (erreurs/bonnes données, etc.). Si tous les tests sortent propres, vous pouvez passer à l'étape suivante et écrire un test pour les autres classes utilisant cette classe de base. Mais il n'y a aucun intérêt à passer à autre chose si votre classe de base n'a pas/n'a pas réussi les tests ou si le débogage devient une jument de nuit. Je n'ai jamais vraiment regardé dans le test d'unité de PHP, j'avais l'habitude d'écrire juste tous les scénarios donnés de cas d'utilisation donnés (IE: Comment les fonctions seraient utilisées/mises en application). C'est une façon générale de penser à quoi écrire un test-case.
Espérons que cela aide.
J'ai écrit une présentation couvrant juste cela comme intro. Espérons que cela fonctionne sans notes de haut-parleurs:
http://www.scribd.com/full/34941838?access_key=key-1u9c5kmupy1889f4o6tv (ce qui est encore une révision précoce, tous les commentaires que vous pourriez me donner serait évalué :)
Il emprunte beaucoup du livre "Test Patterns xUnit: Refonte Test Code " http://rcm.amazon.com/e/cm?lt1=_blank&bc1=000000&IS2=1&bg1=FFFFFF&fc1=000000&lc1=0000FF&t=alex010-20&o=1&p=8&l=as1&m=amazon&f=ifr&md=10FE9736YVPPT7A0FBG2&asins=0131495054"
regardez aussi les présentations par Sebastian Bergmann le créateur de PHPUnit http://talks.php.net/index.php/Testing
Si vous pouvez vous permettre le livre, cela compterait comme ma recommandation numéro un sur l'apprentissage des modèles de test de l'unité.
Enfin (ou peut-être une pensée après) vos prochaines étapes pour obtenir jusqu'à « normes professionnelles » en AQ bénéficierait en passant par le
American Society for Quality:http://www.asq.org/
Avec la achat d'une adhésion (d'environ 50 $ à 150 $ USD), vous pouvez vous inscrire à des cours et obtenir une certification en AQ. En outre, leurs supports de cours (coût inconnu) peuvent être envoyés sur votre lieu de travail pour que vous puissiez vous auto-étudier, passer un test, obtenir une certification et former d'autres personnes en AQ.
Espérons vraiment que cela aide. - Alex
Je viens de trouver facile de commencer tutoriel sur les tests unitaires avec php, qui utilise SimpleTest au lieu de PHPUnit: http://net.tutsplus.com/tutorials/php/the-newbies-guide-to-test-driven-development/
Le site officiel de PhpUnit est d'avoir aussi de bons exemples et tous les pourquoi et le comment.
Jetez un oeil à it
Je commence à apprendre à utiliser correctement TDD et je suis actuellement en utilisant PHPUnit. Je ne saurais trop insister sur la façon dont le travail de l'oncle Bob (Robert C. Martin) m'a aidé. J'ai la chance d'avoir une entreprise qui a offert les vidéos. Mais son travail avec 'Clean Code' est incroyable. Dans les vidéos, il utilise un 'cap' pour basculer entre les différentes étapes de TDD (Red> Green> Refactor) et décrit les étapes avec beaucoup de détails. J'utilise aussi TDD Kata's pour améliorer mes compétences en PHP et TDD. Je crois que l'état d'esprit n'est pas quelque chose que les codeurs sont habitués. Parce que vous code pour corriger un test qui échoue, vous pensez petit plutôt que grand. La séparation de la tâche spécifique que vous faites au code vous empêche de vous égarer trop loin. À un moment donné, vous êtes en train de coder pour réussir un test, réussir un test ou refactoriser votre code - jamais ailleurs. Et parce que ce sont de petites itérations, je crois que ça se passe mieux avec le développeur - c'est avec moi!
Je devrais souligner que je suis un développeur amateur et que je viens juste de commencer (en effet c'est mon premier article!). À mon avis, la première approche du test fonctionne très bien. Cela vous oblige à écrire du code modulaire, car il doit le tester. Vous, à son tour, écrivez un code qui adhère aux principes SOLID.
Allez-y doucement avec moi. J'apprends encore :)
J'ai regardé ce fil pendant des jours, car c'est un sujet que je suis très intéressé. Triste de voir le manque de réponses ... il y a tellement d'opinions divergentes je m'attendais à un vrai combat de chignon. Par exemple, j'ai vu un gars parler en disant qu'il détestait les simulacres - son sentiment général était que la plupart du temps, il avait l'impression de tester le simulacre, pas le code. Allons! Se disputer! – James