Quelques questions sur les tests unitaires

Question

Deux questions sur les tests unitaires.

1. J'ai écrit des tests unitaires pour un certain temps, mais ils sont généralement cours d'essai j'avais déjà écrit. J'ai lu récemment un article (Vous l'esprit un ancien article) qui dit vous devriez écrire des tests unitaires avant vous commencez à écrire votre code.

   quiconque ne suit effectivement ce méthodologie? Il semble être un bon idée sur le papier, mais dans la pratique est il?

2. Pourquoi devriez-vous écrire des tests unitaires pour voir comment votre méthode poignées mauvaise / entrée malicieuse? Il est évident que vous voulez des tests d'écriture contre des fonctions qui sont spécifiquement destinés à la poignée d'entrée « utilisateur » pour voir comment il gère mal / entrée malicieuse, mais qu'en est-fonctions qui ne devrait jamais avoir ce type d'entrée est passé à eux? À quel moment vous tracer la ligne?

Answer 1

La méthode d'écriture des tests unitaires avant les classes est appelée piloté par les tests (TDD de Développement ) et a été popularisé par Kent Beck au début des années 2000. L'idée est que vous écrivez un test qui décrit les fonctionnalités dont vous avez besoin. Dans un premier temps, ce test échouera. Comme vous écrivez votre classe, le test passe. Vous refactoring votre test pour ajouter des fonctionnalités plus désiré, refactoriser alors la classe pour faire de ce nouveau laissez-passer de test. Votre classe a atteint ses objectifs dès que les tests passent. Bien sûr, cette balance au-delà de classes ainsi.

En ce qui concerne les types de tests à écrire, cela dépend si vous testez une API publique ou une API privée. API publiques devraient avoir des tests plus étendus écrits pour faire en sorte que l'entrée est bien formée, surtout si vous ne faites pas confiance entièrement les utilisateurs de votre API. API privées (méthodes qui sont appelées seulement par votre code) peut probablement vous en sortir sans ces tests -. Je suppose que vous pouvez faire confiance à votre propre équipe de développement pour passer pas dans de mauvaises données pour les

Answer 2

Test Driven Development est un concept assez répandu. L'idée de base est que vous essayez de ne écrire du code qui est nécessaire pour satisfaire une exigence du logiciel. Alors, vous écrivez un test pour l'exigence, et le code pour faire passer le test.

Personnellement, je ne sais pas j'utiliser TDD, mais les gens qui le font. Mes pensées personnelles sont qu'il est très utile si vous travaillez sur quelque chose qui est plus axé sur les applications, comme une base de données ou de l'interface utilisateur. Mais, pour quelque chose qui est plus lourd algorithme (comme un modèle physique), je trouve que ça me brise le train de la pensée et obtient de la manière.

Answer 3

L'écriture des tests unitaires première est une pratique assez courante. Un grand avantage est que vous ne vous contentez pas d'écrire des tests que votre code passera, mais plutôt des tests qui définissent ce qui est important, ce que vous essayez d'atteindre, et ce que vous voulez vous assurer n'arrivera pas. Il peut vous aider à étoffer votre conception. En outre, vous pouvez vet la paille avec les parties prenantes externes avant le code que vous.

En ce qui concerne les tests à écrire, qui est un peu subjectif en fonction du temps que vous avez. Je ne voudrais pas aller code vetting fou pour les scénarios, il ne sera jamais confronté. Cela dit, il est étonnant que l'entrée rend le code que « ne le verra jamais ». Ainsi, d'autres tests sont meilleurs, mais il y a certainement des rendements décroissants à un moment donné.

La langue que vous codez en matière. Les langages dynamiques nécessitent plus de tests, car le compilateur attraper moins de problèmes et des bugs peuvent être plus difficiles à suivre (car ils peuvent se propager plus loin la question de l'entrée initiale). Au moins, ceci est mon opinion.

Il fait aussi une différence d'où vient l'entrée. Le grand public devrait être considéré positivement malveillant (ie. Le web), les employés doivent supposer incompétents, et même d'autres codeurs (et vous-même!), Il faut supposer au moins insouciante. Mais le danger diminue à mesure que vous vous approchez de votre cercle intérieur.

Answer 4

  

Est-ce que quelqu'un fait suivre cette méthodologie?

Oui.

  

Il semble être une bonne idée sur le papier, mais en pratique, est-il?

Oui.

  

Pourquoi devriez-vous écrire des tests unitaires pour voir comment votre méthode poignées mauvaise / entrée malicieuse?

Oui.

  

Qu'en est-il des fonctions qui ne devraient jamais avoir ce type d'entrée est passé à eux? À quel moment vous tracer la ligne?

Quand il passe de logiciel à la psychose.

Vous pouvez - si vous voulez - des tests d'écriture pour des situations impossibles. Cependant, vous perdez votre temps et votre employeur est une façon évidente.

Vous écrivez des tests pour définis cas d'utilisation. Et voilà.

Vous ne faites pas les cas de tests aléatoires en fonction de votre imagination.

Et si? si définis cas d'utilisation sont incomplètes? Bummer. Vous écrivez des tests pour l'interface officielle, contractuelle, public - et rien de plus

.

Et si la conception est insuffisante et vous rendre compte que l'interface donnée est truffé de spécifications incomplètes, des contradictions et des failles de sécurité? Cela n'a rien à voir avec l'essai. Ceci est la programmation juste. Une mauvaise conception est mauvaise conception.

Et si certains sociopathe malveillant prend votre code et l'utilise d'une manière qui dépasse (ou ne parvient pas à répondre) aux spécifications définies? Bummer. Le sociopathe gagne. Ils ont été en mesure de mettre votre code dans la situation impossible que vous ne l'avez pas tester pour. Achetez-les une bière pour être si intelligent.

Answer 5

Il y a une différence de mentalité entre test avant et après test. L'écriture des tests avant est une forme de conception , en ce que vous concevez l'interface de votre code et définir le comportement attendu. Ensuite, lorsque vous écrivez du code qui passe les tests, qui valide votre conception. Et à la fin du développement, il vous arrive d'avoir une suite de tests déjà en place!

test après, vous devez être prudent pour éviter le piège de l'écriture de tests que votre code existant passera. Il est un objectif différent, et vous ne recevez pas le maximum de ce que le test avant la version.

Answer 6

Il est déjà tout à fait un bon tas de réponses, mais je voudrais dire encore penser au numéro de la question 2.

Si vous faites votre code unittest « guidée par les données », il importe si le shouldnt code teste « mauvais » ou entrée « bon ». Ce qui importe est que vous avez assez grand ensemble de données qui couvre à la fois.