J'ai une base de code legacy et j'ai besoin de tester ce code avec PHPUnit. Je demande donc des suggestions basées sur vos expériences. Quelles classes je devrais tester en premier? Ou donner la priorité?
Devrais-je commencer par les classes faciles / petites ou avec la base / la classe Super?
3 Réponses :
Il y a souvent trop de code dans un système pour tout tester comme une première étape. Mais la plupart de ce code fonctionne déjà.
Je commencerais avec des méthodes modifiées récemment. Vraisemblablement, la plupart du reste du logiciel fonctionne dans une certaine mesure et des tests qui ne trouveront probablement pas autant d'erreurs que seront trouvées dans le code nouveau ou nouvellement révisé.
Devriez-vous manquer de travail (j'en doute dans un proche avenir si vous avez 1 ou plusieurs développeurs travaillant activement près de vous), vous pouvez passer à des méthodes utiliser les méthodes modifiées , aux méthodes qui ont une complexité élevée en fonction des métriques logicielles et des méthodes critiques pour le fonctionnement du système sans danger (connexion avec mot de passe, stockage de données de charge client, etc.)
Un moyen d'aider à décider quoi examiner les tests Suivant consiste à utiliser un outil de couverture de test. Normalement, on l'utilise pour déterminer la manière dont le logiciel testé est bien testé, mais si vous n'avez pas beaucoup de tests, vous savez déjà avec cela vous dira: Votre code n'est pas très bien testé: - {Il n'y a donc aucun point à l'exécuter tôt dans votre processus de construction de test. (Lorsque vous obtenez plus de tests vous et vos gestionnaires, vous voudrez éventuellement le savoir). Toutefois, les outils de couverture des tests ont également tendance à fournir des listes complètes du code qui ont été exercées ou non dans le cadre de vos tests, et que fournissent un indice sur ce que vous devez tester le nœud: code qui a pas été exercé.
Notre Outil de couverture de test SD PHP fonctionne avec PHP et fournira ces informations , via Viewer interactif et en tant que rapport généré. Il vous indiquera quelles méthodes, classes, fichiers et sous-systèmes (par hiérarchie de répertoire) ont été testés et dans quelle mesure. Si le fichier nommé "login.php" n'a pas été testé, vous pourrez facilement le voir facilement. Et cette vue explicite facilite beaucoup plus facilement de décider intelligemment quoi tester ensuite, que simplement deviner basé sur ce que vous connaissez peut-être sur le code.
De plus, je regarderais des tests d'écriture pour les ajouts et / ou les corrections de bugs tels qu'ils se produisent, tout le nouveau code a une couverture de test.
Bien merci pour la suggestion. Comme ma position maintenant, je suis un stagiaire ici et j'ai reçu les codes du développeur principal où j'ai mon stage. Le fait que les tests agissent également comme un apprentissage incrémentiel de comprendre le système également. Ma tâche principale n'est en fait pas principalement de continuer le code mais de la preuve qui testant les codes avec PHPUNIT ajoutera des avantages aux codes. Cependant, je dois le comprendre d'abord et la planification d'écrire quelle partie des codes à tester
Ma suggestion générale d'introduction de tests d'unités à une base de code existante serait la suivante:
Après cela, je vous suggère de vous concentrer sur trois choses:
PHPUnit vous fournira un rapport de codecoverage vous indiquant comment votre code de code est bien testé. Il peut être assez cool de voir que le nombre augmente de 0,3% à 5% à 20% au cours du mois, mais ce n'est pas un motivateur très fort.
Pour vous assurer de tester le nouveau code, je suggère d'utiliser php_change_couverage comme < Un href = "http://qafoo.com/blog/003_testing_legacy_code.html" rel = "nOfollow NOREFERRER"> Cet outil vous aidera beaucoup à générer des rapports de couverture significatifs, car il ne montre que Avec cela, vous avez quelque chose à portée de main qui rend vraiment facile de "obtenir un plus haut% très tôt et continuez à tester les nouvelles choses" pendant que vous créez des tests pour tout ce qui est vieux.
avant la couverture de changement de PHP:
et après:
décrit dans ce blog affiché
code nouvellement créé comme non testé et non toutes les anciennes choses que vous avez couchées.
+ Oned pour me présenter un nouvel ami. Php_change_couverage a l'air génial, une page de couverture de code rouge tue quelque peu la motivation: o)
regarder PHPure ,
Leur logiciel enregistre les entrées et les sorties d'un site Web de PHP de travail, puis écrit automatiquement des tests PHPUnit pour les fonctions qui n'accèdent pas aux sources externes (DB, fichiers, etc.).
Ce n'est pas une solution à 100%, mais c'est un bon départ