89 votes

Comment avez-vous un test unitaire de test unitaire ?

Je regardais Rob Connerys de webémissions sur le MVCStoreFront Application, et j'ai remarqué qu'il était de tests unitaires, même les choses les plus banales, des choses comme:

public Decimal DiscountPrice
{
   get
   {
       return this.Price - this.Discount;
   }
}

Aurait un test comme:

[TestMethod]
public void Test_DiscountPrice
{
    Product p = new Product();
    p.Price = 100;
    p.Discount = 20;
    Assert.IsEqual(p.DiscountPrice,80);
}

Alors, je suis pour les tests unitaires, je me demande parfois si cette forme de test en premier développement est vraiment bénéfique, par exemple, dans un processus réel, vous avez 3 ou 4 couches au-dessus de votre code (Demande d'Entreprise, les Exigences du Document, du Document d'Architecture), où le réel défini règle d'entreprise (Réduction de Prix est le Prix d'Escompte) pourrait être misdefined.

Si c'est le cas, votre appareil de test ne signifie rien pour vous.

En outre, votre test unitaire est un autre point de défaillance:

[TestMethod]
public void Test_DiscountPrice
{
    Product p = new Product();
    p.Price = 100;
    p.Discount = 20;
    Assert.IsEqual(p.DiscountPrice,90);
}

Maintenant, le test est biaisé. Evidemment, dans un simple test, c'est pas une grosse affaire, mais dire que nous avons test d'un complexe d'affaires de la règle. Que gagnons-nous ici?

Avance rapide de deux ans dans l'application de la vie, lors de l'entretien les développeurs sont à l'entretenir. Maintenant, l'entreprise change son de la règle, et le test de pauses à nouveau, certains recrue développeur fixe alors le test de manière incorrecte...nous avons maintenant un autre point de défaillance.

Je ne vois plus de points possibles de l'échec, sans réelle bénéfique de retour, si la remise des prix est erroné, l'équipe de test trouverez toujours la question, comment avez-tests unitaires enregistrer n'importe quel travail?

Ce qui me manque ici? Apprends-moi à aimer TDD, comme je vais avoir un moment difficile de l'accepter comme utile jusqu'à présent. Je veux trop, parce que je veux rester progressive, mais il n'a tout simplement pas de sens pour moi.

EDIT: UN couple de personnes de garder mentionné que le test de dépistage permet de maintenir la spec. Il a été mon expérience que la spécification a été de mal que de bien, le plus souvent, mais peut-être que je suis condamnée à travailler dans une entreprise où les spécifications sont écrits par des gens qui ne devraient pas être la rédaction de spécifications.

63voto

Jason Cohen Points 36475

Tout d'abord, les tests, c'est comme la sécurité, vous ne pouvez jamais être sûr à 100% que vous avez eu, mais chaque couche ajoute plus de confiance et d'un cadre plus facilement de régler les problèmes qui subsistent.

Deuxièmement, vous pouvez casser des tests dans les sous-programmes qui peuvent alors être testés. Quand vous avez 20 essais similaires, de faire un (testé) sous-routine signifie que votre principal critère est de 20 simples invocations de la sous-routine qui est beaucoup plus susceptible d'être correct.

Troisièmement, certains diront que TDD répond à cette préoccupation. C'est, si vous venez d'écrire, 20 tests et ils passent, vous n'êtes pas entièrement convaincus qu'ils sont en fait des tests de quoi que ce soit. Mais si chaque test que vous avez écrit initialement échoué, et puis vous fixé, alors vous êtes beaucoup plus confiant que c'est vraiment de tester votre code. À mon humble avis ce va-et-vient prend plus de temps que ce qu'il vaut, mais c'est un processus qui tente de répondre à votre préoccupation.

39voto

Steve Jessop Points 166970

Un test de mal, c'est rare de casser votre code de production. Au moins, pas pire que de ne pas avoir de test. Il n'est donc pas un "point de rupture": les tests n'ont pas à être correct pour que le produit fonctionne. Ils pourraient avoir à être correct avant d'être signés comme travail, mais le processus de fixation cassé essais de ne pas nuire à votre mise en œuvre du code.

Vous pouvez penser à des tests, même triviale des tests comme ceux-ci, comme étant un deuxième avis, de ce que le code est censé faire. Un avis est le test, l'autre est la mise en œuvre. Si ils ne sont pas d'accord, alors vous savez que vous avez un problème et vous regardez de plus près.

Il est également utile si quelqu'un dans le futur veut implémenter la même interface à partir de zéro. Ils ne devraient pas avoir à lire la première mise en œuvre, afin de savoir quelle sera la Réduction des moyens, et les tests de loi sans équivoque le back-up pour une description écrite de l'interface que vous pourriez avoir.

Cela dit, vous êtes commercial hors du temps. Si il y a d'autres tests vous pourriez être écrit en utilisant le temps de vous sauver en sautant ces trivial tests, ils seraient peut-être plus précieux. Cela dépend de votre configuration de test et de la nature de la demande, vraiment. Si la Remise est importante pour l'application, puis vous allez attraper tous les bugs dans cette méthode dans des tests fonctionnels, de toute façon. Tous les tests unitaires n'est laissez-vous attraper au point vous êtes le test de cette unité, lorsque l'emplacement de l'erreur est immédiatement évident, au lieu d'attendre jusqu'à ce que l'application est intégrée et l'emplacement de l'erreur peut être moins évident.

Par la façon dont, personnellement, je ne voudrais pas l'utiliser à 100 que le prix dans le cas du test (ou plutôt, si je ne puis j'aimerais ajouter un autre test avec un autre prix). La raison en est que quelqu'un dans le futur pourrait penser que la Réduction est censé être un pourcentage. Un but de trivial des tests de ce genre est de veiller à ce que les erreurs commises dans la lecture de la spécification sont corrigées.

[Concernant la edit: je pense que c'est inévitable qu'une mauvaise spécification est un point de défaillance. Si vous ne savez pas ce que l'application est censé faire, alors les chances sont, il ne le fera pas. Mais l'écriture de tests afin de refléter la spec ne pas amplifier ce problème, il omet tout simplement de le résoudre. Si vous n'êtes pas d'ajouter de nouveaux points de défaillance, vous êtes seulement de représenter les défauts existants dans le code au lieu de gaufre de la documentation.]

22voto

Bill the Lizard Points 147311

Je ne vois plus de points possibles de l'échec, sans réelle bénéfique de retour, si la remise des prix est erroné, l'équipe de test trouverez toujours la question, comment avez-tests unitaires enregistrer n'importe quel travail?

Les tests unitaires n'est pas vraiment censé enregistrer son travail, il est censé pour vous aider à trouver et empêcher les insectes. C'est plus de travail, mais c'est le genre de travail. Il est à penser au sujet de votre code au plus bas niveau de granularité et de l'écriture des cas de tests qui prouvent qu'elle fonctionne sous attendus conditions, pour un ensemble donné d'intrants. C'est d'isoler les variables de sorte que vous pouvez économiser du temps en regardant à la bonne place quand un bug n'est présent lui-même. C'est l' économie de la suite de tests, de sorte que vous pouvez les utiliser encore et encore quand vous avez à faire un changement en bas de la route.

Personnellement, je pense que la plupart des méthodes ne sont pas nombreux, pas de culte du cargo en génie logiciel, TDD inclus, mais vous n'avez pas à respecter de strictes TDD à récolter les avantages de tests unitaires. Garder les bonnes pièces et jetez les parties qui produisent peu d'avantages.

Enfin, la réponse à votre titulaire de la question "Comment avez-vous test unitaire d'une unité de test?" c'est que vous ne devriez pas avoir à. Chaque test unitaire doit être en état de mort cérébrale simple. Appeler une méthode avec une entrée spécifique et de le comparer à sa sortie attendue. Si la spécification d'une méthode de changements, alors vous pouvez vous attendre que certains des tests unitaires pour que la méthode aura besoin d'en changer. C'est une des raisons pour laquelle vous ne tests unitaires à un si bas niveau de granularité, de sorte que seules certaines des tests unitaires doivent changer. Si vous trouvez que les tests pour de nombreuses méthodes différentes sont en train de changer pour un changement d'une exigence, alors vous ne pouvez pas faire les essais à un assez fine au niveau de granularité.

11voto

tvanfosson Points 268301

Les tests unitaires sont là pour que vos unités (les méthodes) de faire ce que vous attendez. L'écriture du test de la première force à réfléchir sur ce que vous attendez avant d'écrire le code. Penser avant de le faire est toujours une bonne idée.

Les tests unitaires doivent refléter les règles métier. Accordé, il peut y avoir des erreurs dans le code, mais d'écrire le test d'abord vous permet d'écrire du point de vue de la règle métier avant tout code qui a été écrit. L'écriture de l'essai par la suite, je pense, est plus susceptible de conduire à l'erreur de vous décrire parce que vous savez comment le code met en œuvre, et sont tentés juste pour s'assurer que la mise en œuvre est correcte -- pas que l'intention est bonne.

Aussi, les tests unitaires ne sont qu'une forme -- et le plus bas, à qui -- de tests que vous devriez écrire. Les tests d'intégration et tests d'acceptation doit aussi être écrit, celui-ci par le client, si possible, assurez-vous que le système fonctionne de la façon dont il est prévu. Si vous trouver des erreurs au cours de ce test, revenir en arrière et écrire des tests unitaires (échec) pour tester le changement de fonctionnalité pour le faire fonctionner correctement, modifiez votre code pour faire le test. Vous avez maintenant des tests de régression qui capture vos corrections de bugs.

[MODIFIER]

Une autre chose que j'ai trouvé à faire des TDD. Il a presque les forces de bonne conception par défaut. C'est parce que très couplé dessins sont presque impossible à l'unité de test dans l'isolement. Il n'est pas très long à l'aide de TDD pour comprendre que l'utilisation d'interfaces, l'inversion de contrôle et l'injection de dépendances -- tous les modèles qui permettront d'améliorer votre conception et de réduire le couplage -- sont vraiment important pour de code de tests.

10voto

Andrzej Doyle Points 52541

Comment fait-on un test? Le test de Mutation est une technique intéressante que j'ai personnellement utilisé pour étonnamment bon effet. Lire l'article lié pour plus de détails, et des liens vers encore plus de références scientifiques, mais en général, il "teste vos tests" par la modification de votre code source (en changeant "x += 1" à "x= 1" par exemple) et en relançant votre tests, en s'assurant qu'au moins un test échoue. Toutes les mutations qui ne sont pas la cause d'échec de test sont marqués pour les enquêtes ultérieures.

Vous seriez surpris de voir combien vous pouvez avoir 100% de la ligne et de la direction générale de la couverture avec un ensemble de tests qui regarder complet, et pourtant, vous pouvez changer fondamentalement ou même de commenter une ligne dans votre code source sans les tests se plaindre. Souvent, cela revient à ne pas tester avec le droit des entrées pour couvrir toutes les limites des cas, il est parfois plus subtile, mais dans tous les cas, j'ai été impressionné par la façon dont beaucoup de est sorti.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X