Dupliqué possible:
Les tests unitaires méritent l'effort?Je sais quel est le but des tests unitaires de manière générale, mais j'ai trouvé des choses qui me dérangent.
1) OBJECTIF DES TESTS DÉTAILLE DÉCOUVERTE DE BUGS. Donc, dans certaines des itérations ultérieures, si je fais des changements de code, le test automatisé doit-il alarmer et me dire que j'ai foiré un morceau oublié depuis longtemps de mon logiciel.
Mais, disons que j'ai la classe A et dire que cela interagit avec une autre instance de classe, appelez la classe b.
Quand on écrit un test de l'unité pour la classe A, il doit se moquer de la classe B. Donc, dans un avenir, si l'on change de la classe B et que cela provoque des bugs, ils ne refléteront que dans le test de l'unité de la classe B, et non dans le test de A ('Cause A's's Test n'utilise pas de la vraie classe B, mais c'est moqueur avec des entrées et des sorties fixes). Donc, je ne vois pas comment le test de l'unité pourrait-il notifier tôt en avertissant des bugs dont on ne sait pas? Je suis au courant d'éventuels bugs en classe que je change, je n'ai pas besoin d'un test d'unité pour cela, j'ai besoin d'un test pour alarmer moi des conséquences de mes changements qui fait bug dans une classe "oubliée" et que ce n'est pas possible avec des tests d'unité. Ou je me trompe?
2) Lorsque vous écrivez des moqueurs et des attentes droites des méthodes d'appel, leurs intrants et leurs valeurs de retour, il faut savoir comment le sous-test de classe sera mis en œuvre. Et je pense que cela contredit avec le développement axé sur le test. Dans TDD One écrit d'abord des tests, et, conduits par eux, on écrit un code. Mais je ne peux pas écrire de bonnes attentes (et tests en général) à moins que je n'en écrit de code qui doit être testé. Qui contredit avec TDD, non?
Ces deux problèmes pourraient être résolus si j'avais utilisé de vrais objets au lieu de moqueurs. Mais ce n'est pas un test unitaire alors, non? Dans le test de test de l'unité, le sous-test doit être isolé, former le reste du système, sans utiliser de vraies classes mais se moque.
Je suis sûr que je me trompe quelque part, mais je ne trouve pas où. J'ai lu et je lisais et je ne trouve pas ce que j'ai mal compris.
5 Réponses :
Strictement parler, vous passez plus de temps à écrire un test de l'unité plutôt que de vous concentrer sur le code réel.
Il n'y a aucun moyen que vous puissiez obtenir une couverture de code à 100%. Je fais tester mon application, mais je sens que ça ne vaut pas la peine. Mais tout le monde n'est pas d'accord avec cela.
Si vous modifiez un morceau de code, votre test d'unité échoue et déterminez pourquoi son échec, mais pour moi, cela ne valait pas la peine.
Je ne suis pas gros fan des tests unitaires ... vous vous moquez de tout mais se moquer de la grosse tâche ..........
Mais maintenant, des sociétés d'une journée éprouvent pour une approche TDD.
Oui, "Si vous modifiez un morceau de code, votre test de l'unité échoue et déterminez pourquoi son échec", mais si vous vous moquez de tout, lorsque je change de méthode, seul ce test de cette méthode pourrait échouer et rien d'autre. Je parle de tests unitaires et non de tests en général. Si je me moque de tout, les changements d'une classe n'auront pas de conséquences dans les tests des autres classes. Si je ne me moque pas de tout, ce n'est pas un test unitaire, autant que je sache.
@sadClown qui n'est pas l'idée d'objets simulés, afaik. Des objets simulés sont utilisés pour représenter, par exemple une demande HTTP. Vous ne testez pas les objets simulés, ils sont utilisés dans votre test et passés au code que vous testez.
réponse simple: oui, ils sont utiles pour réel.
TDD est gentil et tout en théorie, mais je n'ai guère jamais vu le voir dans la pratique. Les instations ne sont toutefois pas liées à TDD. Vous pouvez toujours écrire des informations pour le code qui fonctionne pour vous assurer qu'il fonctionne toujours après des modifications. Cet usage des instances m'a sauvé d'innombrables heures de bugsing car les tests ont immédiatement souligné ce qui s'est mal passé.
J'ai tendance à éviter des moqueurs. Dans la plupart des cas, ils ne valent pas la peine à mon avis. L'utilisation de simili manifestations pourrait rendre mon unit un peu plus d'une intégrationtest, mais cela fait du travail. Pour vous assurer, vos classes fonctionnent comme conçues.
Quelle est l'approche que vous utilisez pour un objet moqueur dans votre code? Y a-t-il une simple magie moqueuse que vous avez à moquer de l'objet? Ou vous n'utilisez pas du tout des objets dans votre code?
Je viens de mettre en œuvre TDD et des tests unitaires pour la première fois. Je pense que c'est génial, et je ne l'ai jamais utilisé dans un environnement d'intégration contigu, où j'imagine que c'est encore plus précieux.
Mon processus:
Je ne peux plus écrire de code sans d'abord écrire son test, il est vraiment d'aide au développement. Vous attrapez tout de suite des bugs, et cela vous aide vraiment à commander mentalement votre code et votre développement de manière structurée. Et bien sûr, tout code qui enfreint les fonctionnalités existantes est prisé immédiatement.
Je n'ai pas encore besoin d'utiliser des objets simulés (en utilisant le ressort, je peux vous éloigner avec la couche de service d'appel et les méthodes de contrôleur directement).
0) Non, ça ne le fait pas. Son stupide, je veux dire. C'est une question parfaitement valable.
Le fait est que la nôtre est une industrie critiquée de balles d'argent et de glisser avec de l'huile de serpent, et si quelque chose n'a pas de sens, vous avez raison de le remettre en question. Toute technique, toute approche de toute partie de l'ingénierie n'est jamais applicable dans certaines circonstances. Celles-ci sont généralement mal documentées au mieux, et elle a donc tendance à se détériorer dans des arguments totalement inutiles de My-Method-Metholy-Than-Than-Thans.
J'ai eu des succès et des échecs avec des tests unitaires et, dans mon expérience, il peut être très utile, une fois correctement appliqué.
Ce n'est pas une bonne technique lorsque vous faites un effort de développement massif de rayures, car tout change trop rapidement pour que les tests de l'unité puissent suivre. C'est une excellente technique lors d'une phase de maintenance, car vous changez une petite partie d'un ensemble plus vaste qui doit encore fonctionner comme censé.
Pour moi, le test unitaire ne concerne pas le développement axé sur les tests, mais la conception par contrat: le test de l'unité vérifie que l'interface n'a pas été violée. De cela, il est assez facile de voir que la même personne ne devrait pas écrire une unité et son test d'unité correspondant, donc pour des produits très petits, comme mes propres projets d'animaux de compagnie, je ne l'utilise jamais. Dans des projets plus importants, je le préconise - mais uniquement si des conceptions de concept sont employées et que le projet reconnaît les spécifications d'interface comme des artefacts importants.
Test unitaire en tant que technique est également sensible à la taille de l'unité. Ce n'est pas nécessairement le cas où une classe est testable seule et, dans mon expérience, la classe est généralement trop petite pour les tests unitaires. Vous ne voulez pas tester une classe en soi, vous souhaitez tester une unité de fonctionnalité. Des fichiers binaires déployés individuellement (installables), par exemple des pots ou des dlls, forment de meilleurs candidats dans mon livre ou des packages si vous êtes dans une langue de style Java.
Les tests unitaires lui-même ne sont pas stupides, cela dépend de votre projet.
Je pense que les tests d'unités sont bons, pas seulement dans le développement de TDD, mais dans n'importe quel type de projet. Le vrai pro pour moi est que si vous enveloppez du code crucial dans votre projet avec des tests unitaires, il y a un moyen de savoir si ce que vous vouliez dire avec elle fonctionne toujours ou non.
Pour moi, le vrai problème est que si quelqu'un est en train de gâcher votre code, il devrait y avoir un moyen pour lui de savoir si les tests sont toujours soulevés, mais pas en les faisant courir manuellement. Par exemple, prenez l'exemple Eclipse + Java + Maven. Si vous utilisez des tests d'unité sur votre projet Maven Java, chaque fois que tout le monde le construit, les tests fonctionnent automatiquement. Donc, si quelqu'un a gâché votre code, la prochaine fois qu'il le construisit, il obtiendra une erreur de console «Build échec», indiquant que certains tests de l'unité ont échoué.
Donc, mon point est le cas: les tests unitaires sont bons, mais les gens devraient savoir qu'ils vissaient les choses sans exécuter des tests chaque fois qu'ils changent de code.
Connexes: Stackoverflow.com/Questtions/286587/ ...