Le test de mutation est-il utile dans la pratique?

Question

Il existe la technologie de test de mutation. Il vérifie, si les tests sont en cours d'exécution, même si vous changez le code. Si tout n'est pas OK, si les tests sont en cours d'exécution, ils ne couvrent pas tous les cas de figure. Il y a certains travaux théoriques sur le sujet, mais je suis intéressé dans la question, si elle est utile dans la pratique? Avez-vous des exemples de la vie réelle, les applications de test de mutation? Cela fonctionne mieux que le simple test-couverture-outils? Ou est-ce inutile?

Quels sont les avantages/inconvénients de l'essai de mutation dans le monde réel?

Answer 1

L'utilité des tests unitaires n'est plus discuté. Ils sont essentiels dans la conception d'une demande de qualité. Mais, comment pouvons-nous juger de leur pertinence? Un code indicateur de la couverture jusqu'à 100% ne signifie pas que le code est 100% testé. C'est juste une vue de code exécuté au cours de l'unité de l'exécution des tests. Le test de Mutation va vous permettre d'avoir plus de confiance dans vos tests.

C'est un processus en deux étapes:

1. Générer des mutants.
2. Vérifiez que les mutations sont trouvées par les tests.

J'ai écrit un ensemble de l' article à propos de ce processus, y compris certains des cas concrets.

Answer 2

J'ai regardé test de mutation il y a quelque temps comme une méthode de vérification de l'efficacité de mon automatisé regession les scripts de test. Fondamentalement, un certain nombre de ces scripts avait oublié des points de contrôle, de sorte alors qu'ils étaient en exercice de l'application testée correctement, ils n'étaient pas de vérifier les résultats par rapport aux données de référence. J'ai trouvé une méthode beaucoup plus simple que de changer le code a été d'écrire une autre application d'apporter des modifications à une copie de la base de référence, et de ré-exécuter les tests à l'encontre de la modification de la ligne de base. Dans ce scénario, un test qui s'est passé était soit défectueux ou incomplet.

Ce n'est pas le véritable test de mutation, mais une méthode qui utilise un paradigme similaire à tester l'efficacité des scripts de test. Il est assez simple à mettre en œuvre, et de l'OMI fait un bon travail.

Answer 3

J'ai joué avec pitest pour un petit, artificiel application:

http://pitest.org/

C'est une java outil qui automatise la génération mutant. Vous pouvez l'exécuter à l'encontre de votre suite de tests, et ça va générer des rapports HTML, indiquant le nombre de mutants ont été tués. Semble assez efficace et ne nécessite pas beaucoup d'effort à mettre en place. Il y a en fait assez peu agréable outils dans le monde Java pour ce genre de chose. Voir aussi:

http://www.eclemma.org/

Pour la couverture.

---

Je pense que les concepts de base de l'essai de mutation sont son. C'est juste une question d'outil de soutien et de sensibilisation. Vous vous battez un compromis entre la simplicité de code traditionnel mesures de couverture et de la complexité de cette technique est - elle vraiment tout se résume à outils. Si vous pouvez générer des mutants, alors il va aider à exposer les faiblesses de vos cas de test. Est-il la peine de l'augmentation marginale de l'effort sur les tests que vous faites déjà? Avec pitest, je l'ai trouvé à tourner des cas de test qui semblait évident.

Le test de Mutation est un angle d'attaque qui est tout à fait différent de l'unité/fonctionnel/intégration de méthodes de test.

1. Vous test votre test de suite - c'est un méta-test de l'ensemble de votre programme de test.
2. Il inspire d'autres tests peuvent ne pas être considéré comme ailleurs.

Answer 4

J'ai récemment fait quelques recherches sur les tests de mutation. Les résultats sont ici:

http://abeletsky.blogspot.com/2010/07/using-of-mutation-testing-in-real.html

En bref: les tests de mutation pourraient donner des informations sur la qualité du code source et des tests, mais ce n'est pas quelque chose de simple à utiliser.

Answer 5

J'ai récemment commencé à pratiquer le test de mutation en C++, et c'est bien mieux que la couverture de code. Dans le cas extrême, il est possible d'avoir 100% de la couverture de code et de 0% de potentiels bugs découverts, (Dans mon cas, il a révélé ~80% de faux bugs) - bien sûr, il dépend de la façon dont vous générer des bugs.

Le principal problème est de trouver un moyen efficace de générer automatiquement un grand nombre de ne pas l'équivalent des mutants, et les tests de suites doit s'exécuter rapidement.

Votre rapport doit également inclure le changement/diff qui n'a pas été détecté par les tests. Alors vous êtes en mesure de corriger les épreuves.