Tests unitaires - Le bénéfice des tests unitaires avec modifications du contrat?

Question

Récemment, j'ai eu une discussion intéressante avec un collègue à propos des tests unitaires. Nous en avons discuté lors de l'entretien de tests unitaires devient moins productif, lors de vos contrats.

Peut-être que quelqu'un peut m'éclairer la manière d'aborder ce problème. Permettez-moi de préciser:

Donc permet de dire qu'il n'y est une classe qui n'a de chouettes calculs. Le contrat est dit qu'il devrait calculer un nombre, ou qu'elle renvoie -1 si elle échoue pour une raison quelconque.

J'ai un contrat de tests qui test. Et dans toutes mes autres tests que je stub cette chouette calculatrice truc.

Alors maintenant, j'ai modifier le contrat, toutes les fois qu'il ne peut pas calculer qu'il va jeter un CannotCalculateException.

Mon contrat tests échouent, et je vais le corriger en conséquence. Mais, tous mes moqué/écrasa les objets continuent d'utiliser l'ancien contrat de règles. Ces tests permettra de réussir, alors qu'ils ne devraient pas!

La question qui se lève, c'est qu'avec cette foi dans l'unité de test, combien de foi peut être placé dans de telles modifications... Les tests unitaires réussir, mais les bugs se produisent lorsque le test de l'application. Les tests à l'aide de cette calculatrice devra être fixé, ce qui coûte du temps et peut même être écrasé/moqué d'un grand nombre de fois...

Comment pensez-vous de cette affaire? Je n'ai jamais pensé thourougly. À mon avis, ces changements pour les tests unitaires, serait acceptable. Si je n'utilise pas de tests unitaires, je voudrais aussi voir de tels bugs surviennent dans la phase de test (par les testeurs). Pourtant, je ne suis pas assez confiant pour signaler ce qu'il en coûtera plus de temps (ou moins).

Toutes les pensées?

Answer 1

La première question que vous soulevez est la soi-disant "fragiles" test de problème. Vous apportez une modification à votre demande, et des centaines de tests casser à cause de ce changement. Lorsque cela se produit, vous avez une conception de problème. Les tests ont été conçus pour être fragile. Ils n'ont pas été suffisamment découplées de la production de code. La solution est (comme dans tous les logiciels de problèmes de ce genre) pour trouver une abstraction qui découple les tests de code de production de telle manière que la volatilité de la production de code est caché pour les tests.

Certaines choses simples qui cause ce genre de fragilité sont:

• Tests pour les chaînes de caractères qui sont affichés. Ces chaînes sont instables, car leur grammaire ou d'orthographe peut changer au gré de l'humeur de l'analyste.
• Les tests de valeurs discrètes (par exemple 3) qui doit être codé derrière une abstraction (par exemple FULL_TIME).
• L'appel de la même API de nombreux tests. Vous devez envelopper l'appel d'API dans une fonction de test de sorte que lorsque les changements de l'API, vous pouvez faire le changement dans un seul endroit.

Test de la conception est un enjeu important qui est souvent négligé par TDD les débutants. Il en résulte souvent fragile tests, ce qui conduit alors les novices à rejeter TDD comme "improductives".

La deuxième question que vous avez soulevée était faux positifs. Vous avez utilisé beaucoup se moque de ce qu'aucun de vos tests de tester le système intégré. Alors que les tests des unités indépendantes est une bonne chose, il est également important de tester partielle et l'ensemble des intégrations du système. TDD est pas seulement à propos des tests unitaires.

Les Tests doivent être disposées comme suit:

• Les tests unitaires fournissent près de 100% de couverture de code. Ils testent des unités indépendantes. Ils sont écrits par des programmeurs à l'aide de la langue de programmation du système.
• Tests d'éléments de couvrir environ 50% des le système. Ils sont écrits par des analystes d'affaires et l'assurance qualité. Ils sont écrits dans une langue comme FitNesse, le Sélénium, le Concombre, etc. Ils permettent de tester l'ensemble des composants, pas des unités individuelles. Ils testent surtout heureux chemin des cas et certains très visible malheureux chemin des cas.
• Les tests d'intégration couvrir environ 20% de la système. Ils tests de petits assemblages de composants, par opposition à l'ensemble du système. Écrit dans FitNesse/Selenium/Concombre etc. Rédigé par architectes.
• Système de tests couvrent environ 10% des le système. Ils permettent de tester l'ensemble du système de façon intégrée. Encore une fois, ils sont écrits dans FitNesse/Selenium/Concombre etc. Rédigé par architectes.
• Exploratoire des tests manuels. (Voir James Bach) Ces tests sont manuel, mais pas sous forme de script. Ils emploient de l'ingéniosité et de la créativité.

Answer 2

Il est préférable d'avoir de fixer l'unité de test qui échoue en raison d'une faute délibérée des modifications de code que de ne pas avoir de tests pour attraper les insectes qui sont finalement instauré par ces changements.

Lorsque votre base de code a une bonne couverture de tests unitaires, vous risquez de rencontrer beaucoup de test de l'unité échecs ne sont pas dus à des bugs dans le code, mais intentionnelle des modifications sur les contrats ou code refactoring.

Toutefois, cette unité de la couverture de test vous donnera également la confiance de refactoriser le code et mettre en œuvre les modifications de contrat. Certains test échouera et devront être corrigés, mais d'autres tests finira par échouer à cause de bugs que vous avez mis en place avec ces changements.

Answer 3

Les tests unitaires ne peuvent certainement pas attraper tous les insectes, même dans le cas idéal de 100% du code / les fonctionnalités de la couverture. Je pense que c'est de ne pas être prévu.

Si l'essai de modifications de contrat, je le développeur doit utiliser mon cerveau pour mettre à jour l'ensemble du code (y compris le code de test!) en conséquence. Si je n'arrive pas à mettre à jour certains se moque de qui, par conséquent, continuent de produire de l'ancien comportement, c'est de ma faute, pas de tests unitaires.

Il est semblable à l'affaire quand j'ai corrigé un bug et produire une unité de test, mais je n'arrive pas à penser (et de tester) tous les cas similaires, certains de qui, plus tard, s'avère être buggy.

Donc oui, les tests unitaires besoin d'entretien ainsi que le code de production lui-même. Sans entretien, de la décomposition et de la pourriture.

Answer 4

J'ai des expériences similaires avec des tests unitaires - lorsque vous modifiez le contrat d'une catégorie souvent vous avez besoin de changer les charges des autres tests (qui vont passer dans de nombreux cas, ce qui rend encore plus difficile). C'est pourquoi j'ai toujours utiliser des tests plus poussés ainsi:

1. Les tests d'acceptation - test à un couple ou à plusieurs classes. Ces tests sont généralement alignés à l'utilisateur des magasins qui doivent être mises en œuvre - afin de vous tester le récit d'utilisateur "œuvres". Ces n'avez pas besoin de se connecter à une base de données ou d'autres systèmes externes, mais peut.
2. Les tests d'intégration - principalement pour vérifier la connectivité au système externe, etc.
3. Pleine de bout en bout, tests - test de l'ensemble du système

Veuillez noter que même si vous avez 100% de couverture de tests unitaires, vous ne sont même pas garanti que votre application démarre! C'est pourquoi vous avez besoin de plus des tests de niveau. Il y a tellement de différentes couches de tests parce que le bas de vous de tester quelque chose, le moins cher c'est souvent (en termes de développement, le maintien de l'infrastructure de test ainsi que le temps d'exécution).

Comme une note de côté - à cause du problème que vous avez mentionné à l'aide de tests unitaires, vous apprend à garder vos composants sont découplés que possible et sur leurs contrats aussi faible que possible - ce qui est certainement un bon exercice!

Answer 5

Quelqu'un a posé la même question dans le Groupe Google pour le livre "cultivons l'Objet de Logiciels Orientés - Guidés par des Tests". Le fil est l' Unité de test maquette/stub hypothèses pourrit.

Voici J. B. Rainsberger de réponse (il est l'auteur de Manning "JUnit Recettes").