Disons que je préfère avoir cette classe qui génère des numéros de fibonacci: i peut alors écrire un test qui veille à ce que les n nombres N dans la séquence sont corrects. P > [Test]
public void GetEnumerator_FirstFifteenNumbers_AreCorrect()
{
var sequence = new FibonacciSequence().Take(15).ToArray();
CollectionAssert.AreEqual(sequence, new[] {1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610});
}
3 Réponses :
Vous devriez utiliser utiliser ienumerable code> (non générique); J'ai posté une réponse en utilisant
Cast
public static int CountUntyped(this IEnumerable source) {
int count = 0;
foreach(object obj in source) { count++; }
return count;
}
IEnumerable<T> source = ...
Assert.AreEqual(typed.Count(), source.CountUntyped());
Mais cela comparerait simplement le nombre d'articles dans les énumérables cependant, n'est-ce pas? Et cela fonctionnerait très mal dans mon cas, car la fibonaccisequence ne finit jamais vraiment: p
MDR! Oui, je prends ton point là-bas. Mais la chose que j'essaie de mettre en évidence fonctionne avec ienumerable code> plutôt que
ienumerable
casting
Edit: mise à jour basée sur ce que Marc a déclaré.
Eh bien, vous pourrait em> obtenir la couverture en faisant: p> // Helper extension method
public static IEnumerable AsWeakEnumerable(this IEnumerable source)
{
foreach (object o in source)
{
yield return o;
}
}
...
[Test]
public void GetEnumerator_FirstFifteenNumbers_AreCorrect()
{
IEnumerable weak = new FibonacciSequence().AsWeakEnumerable();
var sequence = weak.Cast<int>().Take(15).ToArray();
CollectionAssert.AreEqual(sequence,
new[] {1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610});
}
Non - j'ai vérifié et Cast
comme code> pour
ienumerable
IEnumerable
ienumerable.getenumerator () code>
C'est ce que j'ai vu aussi. Alors alors je n'étais pas tout à fait sûr comment y aller, hehe.
Effectivement fini par faire quelque chose de similaire à cela. Et j'ai pensé que je pouvais juste sauter tout le couteau et prendre la chose aussi, je viens de l'envoyer dans la collectionSsert comme c'est. Retour à 100% Couverture de test: P
Ce que j'ai fini par faire, car comme j'ai commenté Marc avoir des séquences infinies, devait mettre en œuvre une méthode code> code> pour NONGENERIC iEnumerable code> :)
Je ne le testerais pas. J'essaierais de filtrer la méthode hors de l'outil de couverture. Je pense que la couverture devrait vérifier les choses que je veux couvrir et non tout. D'autres commentaires, vous semblez utiliser Testdriven.net. Je ne sais pas à quel point cela filtre mais c'était possible avec NCOver. Vous pouvez essayer le couvertiver également. P>
Bien sûr, et je ne me frappe pas sur ceci ou quoi que ce soit. Juste curieux de voir comment les autres traitent avec ça :)
@Svish - Désolé, la réponse sonne sonnée que je voulais. Mais je regarderais vraiment la filtration des choses. Je pense que c'est mieux que d'essayer d'ajouter un test pour cela.
Les tests d'unités sont le seul type d'essai où il est très économiquement réalisable d'atteindre une couverture de 100% de code. Si vous n'obtenez pas là-bas, vous ne l'atteindrez probablement jamais du tout, car le coût de la couverture augmente de manière exponentielle avec le nombre de composants dans les tests d'intégration / fonctionnels. Si vous n'obtenez pas 100% de couverture à un certain niveau dans vos suites de test, vous expédiez des bugs pour votre client pour découvrir pour vous, que vous pourriez facilement avoir évité. Et la couverture de 100% est également une excellente aide pour le refactoring, ainsi que la cause occasionnelle.
@jwdonahue un bon point, mais je pense toujours filtrer, c'est mieux dans ce cas. Mesurer la couverture sur ce qui est logique de tester. Dans ce cas, l'OP vous demandait de tester la méthode ienumerable.getenumerator () uniquement. Je suggérant que depuis que cela ne fait que déléguer que vous devriez essayer de l'exclure de la couverture, car il ne fait que tester le code de la méthode déléguée et couvre donc essentiellement la même méthode. C'est certainement discutable.
HMM, hors de curiosité Comment vérifiez-vous la couverture de test? Cela ressemble à une fonctionnalité intéressante.
Ouais, je me suis demandé à ce sujet aussi, hehe. Mais trouvé un bouton pour celui-ci dans Testdriven.net, qui est assez génial à la manière. Si vous n'avez pas essayé, vous devriez! Une fois qu'il est installé, vous pouvez cliquer avec le bouton droit de la souris sur votre solution (dans l'explorateur de solutions) et sélectionnez Test avec -> Couverture. Facile comme ça :)
Si vous avez une édition de système d'équipe VS, les outils de test incluent également un outil de couverture, que vous pouvez déclencher avec Testdriven.net ou dans l'interface ordinaire. Sinon, si vous avez des outils de couverture de test Google pour Visual Studio, il y en a plusieurs. NCOVER pourrait être le plus utilisé.