Attribut/Configuration pour répéter des tests avec VS2008

Bonjour,

Comment faire pour répéter l'execution d'un ensemble de méthode ou classe de tests ?

Disons que j'ai une méthode AdditionTest, comment faire pour configurer ce test de telle façon que la méthode soit répétée en execution par exemple 100 fois sans avoir besoin de cliquer 100 fois sur le bouton run test ?


Dans l'aide de visual studio il me renvoit vers le fichier de configuration de série de test mais je ne trouve rien dans ce fichier de configuration pour la répétition d'un test et rien sur msdn de clair la dessus.


merci par avance.

Salut,
Je ne sais pas quel framework de test tu utilises, mais avec NUnit c'est super simple : http://www.nunit.org/index.php?p=repeat&r=2.5.7

j'utilise le framework 3.5...

D'ailleurs j'ai posé la question pour VS2008 mais c'est aussi valable pour VS2010.


PS : Je n'utilise (plus) nunit et ma question porte sur les tests avec la suite Microsoft.

Quand je parlais de framework je parlais de framework de test (nunit, mbunit, ...), pas de framework .Net.
Vu que tu ne l'avais pas précisé j'ai répondu pour nunit vu que c'est le seul que j'ai utilisé.
J'ai rapidement cherché dans la documentation et je ne trouve pas d'équivalent pour le framework de microsoft.
Mais je présume que rien ne t'empêche d'écrire une fonction qui appel X fois ta méthode de test.
Un truc genre :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

[TestMethod] public void RepeatedTest() { for(int i = 0; i < 10; i++) MonTest(); }   [TestMethod] public void MonTest() { // Ton test actuel ... }

---

Il s'agit bien entendu du framework de microsoft.

Ta solution est intéressante cependant il faudrait enlever l'attribut TestMethod pour le test actuel et ne laisser que le TestMethod pour le RepeatTest.

C'est intéressant mais gênant parce que cela m'oblige à remanier mes tests (et il y en a pas mal) alors qu'avec un attribut repeat le tour était joué sans avoir à modifier quoique se soit.

Je suis bien d'accord avec toi sur le fait qu'un attribut aurait été mieux (c'est d'ailleurs la solution que j'avais proposée avec NUnit), mais en l'occurrence d'après la documentation il n'existe pas pour le framework de Microsoft.

En conséquence je ne vois que cette solution.
Tu n'es pas obligé d'enlever l'attribut sur le test actuel, la seule conséquence c'est qu'il sera lancé une fois tout seul par le biais du processus de test, puis X fois par l'appel effectué dans l'autre test.

Attribut ou méthode, de toute façon il faudra remanier tous les tests à répétition.
La méthode est tellement toujours identique que si tu en as vraiment beaucoup tu peux prendre le temps d'écrire des macros et/ou snippets qui vont te mâcher le boulot.

En fait s'il n'existe pas d'attribut repeat dans l'outil de microsoft alors plutôt que de passer par ta solution qui nécessiterait de modifier mon code pour finalement pas grand chose je préfére dans ce cas écrire un script (un .bat par exemple) qui va lancer l'executable du test x fois. L'avantage c'est que je ne touche pas à mon code d'un iota je ne fais qu'ajouter un script en plus.


D'après ma maigre lecture la répétition des tests est possible à faire dans le fichier de configuration de série des tests mais seulement pour les projets web...

Oui, c'est une autre solution, mais il y a une différence notable tout de même.
Avec ma solution, le test est joué X fois et il doit impérativement passer à chaque fois. Si le teste ne fonctionne pas la 3ième fois, alors la méthode RepeatedTest échoue et est considérée comme un seul et unique échec et la fonction se termine immédiatement, autrement dit si tu as demandé 10 répétitions, seuls les 3 premières seront jouées, les autres seront ignorées.

Par script batch, tu relance le tout X fois, ce qui donne X résultat de tests.
Si tu as 100 méthodes de tests et que tu lance 100 fois, ca te fait 10 000 résultats. Ca fait beaucoup plus de données à analyser.

Ce n'est pas vraiment un avantage ou un inconvénient, tout dépend de ce que tu souhaites.
La première méthode donne un jeu de résultat et teste qu'une méthode n'échoue pas même quand elle est répétée X fois.
La seconde méthode donne X jeux de résultat et teste qu'une méthode n'échoue pas quand elle est appelée une fois.

Cependant, comme je te l'ai dit tout à l'heure, tu peux écrire un petit code qui va générer le code de répétition.

Ce sont bien 2 solutions différentes avec des perspectives différentes.

Je vais y réfléchir parce que ta solution me permet en fait de ne pas modifier de code existant mais d'en rajouter (les methodes repeat) ce qui reste assez simple à programmer puisqu'il suffit de faire une boucle et d'appeler l'existant. Et surtout cela réponds à ma problèmatique sans ajouter ou soustraire quoique se soit.


Avec ma solution je ne modifie rien ni ajout ni modification dans le projet de test mais cela se rapproche un peu trop d'un process d'intégration continu car on pourrait aussi plus facilement derrière faire aussi du reporting. Le nombre de résultat a analyser n'est en soit pas un problème à mon sens au contraire pour faire des statistiques il vaut mieux avoir beaucoup de résultat.


Merci pour ton aide parce j'ai utilisé différents framework de tests ces dernières années et donc des façons de faire différentes quasi à chaque fois. Par exemple avec dunit il n'y a pas d'attribut repeat mais il y a des classes RepeatTest prévues.

Ta solution ressemble un peu à ce que l'on ferait avec dunit..