Question

Dis, j'ai le test suivant:

    [Test]
    public void MyTest( [RandomNumbers( Count=100, Minimum=0, Maximum=1000 )] int number )
    {
        ...
    }

Et à un moment donné, au cours de mon processus régulier de construction, il a échoué. Je suis une notification par e-mail et a entrepris d'approfondir.

Maintenant, quand j'ouvre le test dans Visual Studio et cliquez sur « Exécuter les tests », il passe. Je le fais à nouveau, et il passe à nouveau. Et encore. Et encore. De toute évidence, l'échec était lié à cette séquence particulière de nombres aléatoires.

La question est: Comment puis-je ré-exécuter ce test avec cette séquence exacte (À condition d'avoir le rapport complet Gallio)



UPDATE :
(Suite à un commentaire à ce sujet d'être une mauvaise idée)

Première , je ne demande pas en fait que ce soit une bonne idée. La question est différente.

Deuxième , lorsque le système testé est assez complexe, et l'espace de données d'entrée est de multiples dimensions indépendantes, brisant correctement que l'espace dans les régions équivalence présente un défi important à la fois l'effort mental et le temps, ce qui est tout simplement pas la peine, à condition de plus petits composants du système ont déjà été testés sur leur propre. En même temps, si je peux juste pousser le système ici et là, pourquoi ne pas le faire?

Troisième , je suis en fait pas un débutant dans ce domaine. J'ai toujours utilisé cette technique avec d'autres cadres de test (tels que csUnit et NUnit), et il a été très réussi à attraper des bugs subtils. À l'époque, il n'y avait pas de tels concepts que les données générées, nous avons donc utilisé nos propres béquilles sur mesure, sous la forme d'System.Random avec une graine prédéterminée. Cette semence a été générée dans le cadre de l'initialisation du dispositif (généralement basé sur le temps en cours) et soigneusement écrit pour ouvrir une session. De cette façon, lorsque le test a échoué, je pouvais prendre la graine de journal, branchez-le dans le dispositif d'essai, et d'obtenir exactement le même ensemble de données de test, et donc, exactement le même défaut de débogage.

quatrième , si elle est une mauvaise idée, pourquoi l'exist usine RandomNumbers en premier lieu?

Était-ce utile?

La solution

Il n'y a pas intégré façon Gallio / MbUnit pour générer à nouveau la même séquence de nombres aléatoires. Mais je pense que cela pourrait être une caractéristique utile et je l'ai ouvert un problème pour cette demande. Je vais mettre à jour la réponse du sujet quand il est prêt.

Ce que je propose est le suivant:

  • Afficher la graine réelle du générateur aléatoire interne comme annotation dans le rapport d'essai.
  • Expose une propriété Seed aux attributs de [RandomNumbers] et [RandomStrings] et aux générateurs de données couramment aussi bien.

Ainsi, vous pouvez facilement générer de nouveau la séquence exacte même des valeurs en alimentant le générateur avec le même nombre de graines.

UPDATE : Cette fonction est désormais disponible dans Gallio v3.3.8 et versions ultérieures.


Maintenant, nous sommes tous d'accord avec ce qu'a dit Péter. En utilisant des nombres aléatoires en entrée pour les tests unitaires est rarement une bonne idée. Le corollaire est qu'il est parfois pratique et la plupart du temps approprié. Et c'est exactement la raison pour laquelle nous avons décidé de mettre en œuvre cette fonctionnalité dans MbUnit. À mon humble avis, un scénario commun qui pourrait bien cadrer avec l'entrée de test aléatoire est

scroll top