Existe-t-il des cadres de test pour le développement de logiciels numériques

J'ai constaté que beaucoup de mes programmes de science informatique ont des exigences de test qui ne sont pas couvertes par les cadres de test standard:

1. Test de temps de calcul

   • Pour vous assurer que les algorithmes ne ralentissent pas. Je pourrais faire quelque chose comme assureSmallerEqual(RuntimeWrapper(algorithm),53)mais j'aimerais que le seuil de 53 secondes soit continuellement réduit pendant que je travaille sur l'algorithme, c'est-à-dire quelque chose commeassureSmallerEqual(RuntimeWrapper(algorithm),'previousbest+noisetolerance')

2. Test de performance

   • Pour s'assurer qu'un algorithme qui a précédemment trouvé une bonne approximation d'une solution analytique trouve toujours une solution au moins aussi bonne ou meilleure. Encore une fois, cela pourrait être une émulation par un test d'intégration standard, mais j'aimerais que la tolérance diminue de façon continue à mesure que l'algorithme s'améliore. Pensez à remplacer assureAlmostEqual(foo(),1,places=3)parassureAlmostEqual(foo(),1,places='previousbest')

3. Test des exigences physiques

   • Pour vous assurer que les algorithmes n'ont pas soudainement besoin de plus d'espace mémoire / disque dur. Très similaire à 1.

4. Test des exigences abstraites

   • Pour vous assurer qu'un algorithme qui fonctionnait correctement avec des approximations quadratiques n'a pas soudainement besoin d'approximations cubiques, ou qu'un algorithme qui fonctionnait correctement avec le pas de temps 0,1 n'a pas soudainement besoin de 0,01 pour la stabilité. Encore une fois, ceux-ci pourraient être émulés par des tests d'intégration standard, mais l'objectif est de se souvenir du plus petit paramètre d'exigence qui a atteint un certain objectif, ce qui nécessiterait beaucoup de mises à jour manuelles. Par exemple, si foo(10)auparavant il n'y avait pas d'exceptions, j'aimerais que le framework s'assure que cela foo(10)fonctionne toujours et essaye aussi s'il foo(9)fonctionne maintenant (auquel cas tous les tests futurs garantiraient foo(9)qu'il fonctionne toujours).

On pourrait faire valoir que ce que je demande ne décrit pas les tests dans le sens de tests unitaires / d'intégration, car l'augmentation des durées d'exécution, par exemple, pourrait être acceptable en échange d'autres améliorations.
Dans la pratique, cependant, je sais que j'aurais économisé beaucoup de temps de débogage si j'avais eu la fonctionnalité de test ci-dessus, car dans 95% des cas, les exigences et les performances ont mal tourné en raison des bogues que j'ai introduits. En effet, je sais pertinemment que beaucoup de bogues que j'ai trouvés (après beaucoup de temps perdu à vérifier mon propre code) avec des bibliothèques de logiciels numériques externes auraient pu être évités trivialement si les tests ci-dessus avaient été appliqués rigoureusement.

PS

La question du même nom /programming/34982863/framework-for-regression-testing-of-numerical-code n'est pas un doublon car elle décrit une fonctionnalité qui est plus facilement réalisable avec les cadres de test de régression standard.

La question Stratégies pour les tests unitaires et le développement piloté par les tests demande des stratégies par opposition à un cadre qui aide à les mettre en œuvre (et les stratégies qu'il demande / qui sont fournies dans les réponses sont différentes de ce que je décris ici, à mon avis).

1. Ce type de test me semble mal défini car sa condition de test est liée à la machine particulière sur laquelle vous avez effectué des tests en cours de développement. L'un des points de test est que l'exécution de vos tests sur mon ordinateur portable me dit s'il y a un problème avec le code ou l'environnement que j'ai configuré. Les 53 secondes sont spécifiques à votre machine de développement et le temps d'exécution augmentera également si la machine de test est sous la charge d'autres charges de travail ou utilisateurs. Je ne m'attendrais pas à ce que les frameworks de test résolvent ceci: "la fonction s'exécute en entrée en moins de 53 secondes" n'est tout simplement pas une très bonne spécification de correction.

2. Je pense que cela est ambigu et indésirable du point de vue des tests de logiciels pour les mêmes raisons 1 , vous perdez la justification de réussite ou d'échec pour les tests de logiciels.

3. C'est assez courant, permettez-moi de décrire une solution. Ce n'est pas tout à fait le travail d'un framework de test, mais vous pouvez utiliser un outil séparé comme décrit dans la question Unix SE Limiter l'utilisation de la mémoire pour un seul processus Linux . Un outil standard à essayer en premier est la ulimitcommande in bash, qui vous permet d'exécuter un processus et de vous assurer qu'il se bloque s'il essaie, par exemple, d'allouer trop de mémoire. Donc, si vous exécutez le runtestsscript avec une limite de mémoire, il se bloquera et le framework de test devrait être capable de gérer cela comme un échec de test normal.

4. La plupart des cadres de test ne pense pas que des tests unitaires ainsi du tout . La suite de tests est exécutée (par exemple, avant de valider le code à maîtriser ou avant le déploiement), et le résultat est oui ou non indiquant si elle fonctionne. Les frameworks de test ne considèrent pas que cela fait partie de leur travail, par exemple, de suivre la progression des fonctionnalités, et ce n'est pas ce que les tests sont généralement. Ce que vous feriez ici, c'est que vous écririez deux tests expect_succeeds(foo(10)); expect_fails(foo(9)). Chaque fois, les deux tests sont exécutés et les succès et les échecs attendus passent. Lorsque vous l'implémentez foo(9)et que cela réussit, le test s'attend à l'échec échoue maintenant, vous devez donc réécrireexpect_succeeds(foo(9)), et c'est une fonctionnalité absolument standard de tous les frameworks. Mais vous devez être explicite sur le comportement que vous attendez, car sinon, cela va trop à l'encontre des idées de base des tests de logiciels.

$A$$A$$A$$B$performs_better(foo_A(), foo_B())$B$$A$$B$, et (b) il n'y a plus de sens de comparer le code à ce qu'il était, tous les codes et tests sont désormais immuables et sans ambiguïté. C'est semblable dans l'esprit à la façon dont on pourrait gérer les réécritures du système.