Voici mon expérience avec MS Test
- Nous utilisons MS Test avec environ 3800 tests.
- Il faut beaucoup de temps pour que les tests commencent à s'exécuter, ce qui est pénible lorsque l'on exécute des tests individuels.
- Il faut environ 1 Go de mémoire pour exécuter les tests. Non, ce n'est pas dû à des fuites de mémoire dans nos tests. Nous rencontrons fréquemment des exceptions de type "OutOfMemoryException".
- Parce qu'il utilise beaucoup de ressources, nous commençons à exécuter les tests à partir de fichiers batch. À quoi sert donc toute cette intégration ?
- Il est bogué et instable :
- Par exemple, si vous supprimez l'attribut [Ignorer] d'un test, il ne le reconnaîtra pas, car il met en cache les informations relatives aux tests. Vous devez actualiser la liste des tests, ce qui résout parfois le problème, ou redémarrer VS.
- Au hasard, il ne copie pas les assemblages de référence dans le répertoireout.
- Les éléments de déploiement (fichiers supplémentaires à utiliser) ne fonctionnent pas correctement. Ils sont ignorés de manière aléatoire.
- Les fichiers vsmdi et testrunconfig contiennent des informations cachées (non visibles dans le code de test). Si vous n'en tenez pas compte, il se peut que cela ne fonctionne pas.
- D'un point de vue fonctionnel, il peut être comparé à NUnit, mais il est très cher si vous envisagez d'utiliser l'édition testeur de VS.
Ajout : Nous avons encore d'autres tests à faire, mais je ne peux même pas dire combien. Il n'est plus possible de les exécuter tous à partir de Visual Studio, à cause d'exceptions OutOfMemoryExceptions et d'autres problèmes d'instabilité. Nous exécutons les tests à partir de scripts. Il serait facile de visualiser les résultats des tests dans Visual Studio, mais lorsque la solution est ouverte, VS plante (à chaque fois). Nous devons donc rechercher les tests qui échouent à l'aide d'une recherche textuelle. Il n'y a plus d'avantage à utiliser un outil intégré.
Une autre mise à jour : Nous utilisons maintenant VS 2013. Beaucoup de choses ont changé. Ils ont réécrit le programme de test MS Test pour la troisième fois depuis que nous avons commencé. Cela a entraîné de nombreuses ruptures, mais aucune des deux nouvelles versions ne s'est améliorée. Nous sommes heureux de ne pas avoir utilisé les fonctionnalités fantaisistes de MS Test, car elles ne sont plus supportées. C'est vraiment dommage. Nous utilisons toujours scripts pour construire et exécuter tous les tests unitaires, parce que c'est plus pratique. Visual Studio avait besoin de quelques minutes pour commencer à exécuter les tests (mesures de temps après la compilation jusqu'à ce que le premier test démarre). Il est probable qu'une mise à jour corrige ce problème et qu'il s'agisse d'un problème spécifique à notre projet. Cependant, Resharper est beaucoup plus rapide lors de l'exécution des mêmes tests.
Conclusion : Au moins en combinaison avec Resharper, MS Test est utile. Et j'espère qu'ils ont finalement trouvé comment le test runner devrait être écrit et qu'ils ne feront pas ce genre de changements lors de la prochaine mise à jour de Visual Studio.
12 votes
Envisagez également xunit, mais quoi qu'il en soit, jetez un coup d'œil à TestDriven.net
0 votes
Voir aussi stackoverflow.com/questions/707444/
0 votes
Essayez xunit.net. Il s'agit d'une source ouverte et d'un cadre de test unitaire efficace pour les applications .net.