11
votes

C #: Comment testez-vous la méthode ienumerable.getenumerator ()?

Disons que je préfère avoir cette classe qui génère des numéros de fibonacci: xxx pré>

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 commentaires

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é.


3 Réponses :


4
votes

Vous devriez utiliser utiliser ienumerable code> (non générique); J'ai posté une réponse en utilisant Cast code>, mais qui trichera toujours (elle vérifie le type souhaité comme cas spécial) - Vous avez peut-être besoin de quelque chose comme:

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());


2 commentaires

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 plutôt que ienumerable - et je ne pense pas que vous puissiez simplement utiliser casting , 'parce qu'il a l'air ...



12
votes

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});
}


4 commentaires

Non - j'ai vérifié et Cast vérifie en fait via comme pour ienumerable , vous finirez donc pas en utilisant IEnumerable .getenumerator () , pas ienumerable.getenumerator ()


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 pour NONGENERIC iEnumerable :)



3
votes

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.


4 commentaires

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.