Comment tester les unités liées aux mathématiques?

Question

Je donne un sérieux coup de main à TDD aujourd'hui et je l'ai trouvé très utile, en accord avec tous les éloges qu'il reçoit.

Dans ma quête d'exercices sur lequel pour apprendre à la fois Python et TDD j'ai commencé à le code des exercices de SPOJ en utilisant la technique TDD et je suis arrivé à une question:

Étant donné que tous les exercices de SPOJ sont pour la plupart mathématiques appliquées à la programmation; Comment tester une procédure mathématique comme dans TDD Fashion? Échantillon de données connues pour être correctes? Test contre une implémentation connue? J'ai trouvé que l'utilisation des données d'échantillon données dans le problème lui-même est précieuse, mais il semble exagéré pour quelque chose que vous pouvez tester si rapidement en utilisant la console, sans oublier le surdébit pour concevoir vos algorithmes de manière testable (Proxying the Les objets stdout et stdin sont tout simplement trop de travail pour une très petite récompense), et bien que cela soit bon parce que cela vous oblige à penser vos solutions en termes testables, je pense que je vais peut-être essayer trop dur.

Tous les conseils sont les bienvenus

Answer 1

entrées Utilisez des exemples pour lesquels vous connaissez les résultats (sorties). Utilisez le partitionnement d'équivalence pour identifier un ensemble approprié de cas de test. Avec le code mathématique, vous pouvez trouver que vous ne pouvez pas implémenter de façon incrémentielle comme pour un autre code: vous pourriez avoir besoin de plusieurs cas de test pour chaque amélioration incrémentielle. Je veux dire par là que le code non-mathématique peut typiquement être considéré comme ayant un ensemble de "caractéristiques" et que vous pouvez implémenter une fonctionnalité à la fois, mais le code mathématique ne ressemble pas beaucoup à cela.

Answer 2

tester tous les boîtiers de bord. Votre programme est le plus susceptible d'échouer lorsque l'entrée est spéciale pour une raison quelconque: valeurs négatives, ou zéro, très grandes valeurs, entrées dans l'ordre inverse, entrées vides. Vous pourriez aussi vouloir des tests destructifs pour voir à quel point les intrants peuvent être gros avant que les choses ne se brisent ou ne s'arrêtent.

Sphere online Judge peut ne pas être le meilleur ajustement de TDD. Pour un, les données d'entrée pourraient être mieux comportées que ce qu'une personne réelle pourrait mettre en. Deuxièmement, il y a une limite de taille de code sur certains problèmes. Une suite de tests étendue peut vous faire dépasser cette limite.

Answer 3

Vous voudrez peut-être jeter un coup d'œil à "Transformation Priority Premise" de Uncle Bob. Il offre quelques conseils sur la façon de choisir une séquence de tests pour tester un algorithme.