Question

Je veux tester un algorithme en utilisant des simulations. L'algorithme - dans l'implémentation actuelle - effectue une itération sur une classe de conteneur en plusieurs passes et définit () s et récupère les valeurs de () à partir de celle-ci. Le but du test est de vérifier le résultat final, stocké dans le conteneur. La valeur finale dépend des valeurs lues et écrites entre les passes. par exemple. la valeur de tout élément peut changer plusieurs fois jusqu'à ce que l'algorithme soit terminé et, très probablement, sa valeur à la suite de l'itération n dépendra de sa valeur après l'itération n-1.

J'aime l'idée des mocks et j'adorerais les utiliser dans le scénario décrit ci-dessus car cela me permettrait de vérifier le comportement erroné de l'algorithme une fois qu'il se produit, pas seulement lorsque le calcul est terminé. Cependant, je ne suis pas sûr que ce soit réellement une bonne idée car je devrais alors lier les attentes pour le simulacre très proche de l'implémentation actuelle (par exemple, "attendez obtenir (élément n) et retournez x, puis définissez ( élément n, valeur x + 1), un autre get (n) et retourne x + 1, puis attendez ensemble (n, x + 2) etc. ").

Bien que me permettant de vérifier que les valeurs intermédiaires sont comme prévu, je pense que de telles attentes contrediraient le but du test (vérifier que l'algorithme calcule la valeur finale correcte) et que le test échouerait probablement si l'implémentation change, indépendamment de l'exactitude de la valeur finale.

Maintenant ma question: est-ce que je manque quelque chose? Existe-t-il néanmoins un bon moyen d'utiliser des simulacres dans ce scénario? ou est-ce que cela n'a tout simplement aucun sens de les utiliser ici? Comment les autres traitent-ils ce problème?

Dernière remarque: je parle de tester le code C ++ et d'utiliser googlemock, si cela fait une différence dans votre réponse.

ps: J'ai vérifié Google et les articles ici (en particulier Comportement itératif moqueur - ne s'attaque qu'au problème de augmentant une valeur de retour), cependant, je n'ai rien trouvé proche de mon problème.

Était-ce utile?

La solution

Je dirais que si le conteneur est lent d'une certaine manière ou s'il a des effets secondaires qui signifient que vous ne pouvez pas lire ses valeurs sans le déranger, alors vous devriez utiliser une simulation.

Sinon, utiliser un simulacre est une perte de temps.Souhaitez-vous utiliser une version simulée de std::vector?Je ne le ferais pas;ce serait idiot.

Avec vos tests unitaires, si vous ne pouvez pas tester tout l'état interne de votre algorithme via divers paramètres publics, alors ces états n'ont pas vraiment d'importance.Ils ne peuvent jamais être utilisés réellement.Donc, tant que vous obtenez la bonne réponse finale de votre algorithme pour chaque ensemble de paramètres d'entrée, je dirais que les choses fonctionnent bien.

Autres conseils

Créez votre test unitaire pour la sortie finale de l'algorithme.Vous voulez que vos tests automatisés vérifient le résultat attendu, car c'est ce que les autres parties du programme utiliseront.

En ce qui concerne le test des étapes individuelles dans le code de l'algorithme, il s'agit davantage d'un travail de progression avec un débogueur - pas de tests automatisés.Passer en revue le fonctionnement interne de l'algorithme devrait être une chose ponctuelle, et une fois que vous l'avez bien fait, il n'est pas nécessaire de continuer à tester des étapes individuelles.

Les tests unitaires seraient plus applicables sur les plus petites parties qui composent l'algorithme.

Cela étant dit, les outils de test unitaire sont très utiles pour développer des algorithmes de cette façon.Ils ne sont pas du tout mauvais à utiliser, ne les gardez pas s'ils ne sont plus valides.Habituellement, vous ne testez pas chaque itération dans un test d'intégration, vous testez simplement les résultats.S'il est utile de développer l'algorithme de cette façon, allez-y.

Vous avez raison sur les simulations, vous ne testez pas vraiment beaucoup.Ils peuvent être utiles si vous souhaitez contrôler certaines des entrées.Plusieurs fois, je permuterai mes entrées de manière exhaustive lorsque j'ai des boîtes noires que je ne peux pas contrôler.Cependant, ces types de tests durent trop longtemps.Je les commenterai généralement entièrement ou partiellement lorsqu'ils entreront dans le contrôle de code source.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top