NUnit vs. MbUnit vs. MSTest vs. xUnit.net

Question

Il existe un grand nombre de frameworks d'unittesting pour .NET. J'ai trouvé cette petite comparaison des fonctionnalités : http://xunit.github.io/docs/comparisons.html

Maintenant je dois choisir le meilleur pour nous. Mais comment ? Est-ce important ? Lequel est le plus à l'épreuve de l'avenir et a un élan décent derrière lui ? Dois-je me préoccuper des fonctionnalités ? Alors que xUnit semble être le plus moderne et spécifiquement conçu pour .NET, NUnit semble être celui qui est largement accepté. MSTest est lui aussi déjà intégré à Visual Studio ...

Answer 1

Je sais que c'est un vieux fil de discussion, mais j'ai pensé que je pourrais voter pour xUnit.NET . Alors que la plupart des autres cadres de test mentionnés sont tous à peu près les mêmes, xUnit.NET a adopté une approche unique, moderne et flexible des tests unitaires. Il modifie la terminologie, de sorte que vous ne définissez plus des TestFixtures et des Tests... vous spécifiez des Faits et des Théories sur votre code, ce qui s'intègre mieux avec le concept de ce qu'est un test dans une perspective TDD/BDD.

xUnit.NET est également EXTRÊMEMENT extensible. Ses classes d'attributs FactAttribute et TraitAttribute ne sont pas scellées et fournissent des méthodes de base redéfinissables qui vous donnent beaucoup de contrôle sur la façon dont les méthodes décorées par ces attributs doivent être exécutées. Bien que xUnit.NET, dans sa forme par défaut, vous permette d'écrire des classes de test qui sont similaires aux tests NUnit avec leurs méthodes de test, vous n'êtes pas du tout limité à cette forme de test unitaire. Vous êtes libre d'étendre le cadre pour prendre en charge les spécifications de type BDD Concern/Context/Observation, comme illustré ci-dessous. ici .

xUnit.NET prend également en charge les tests de style fit directement à partir de la boîte avec son attribut Theory et les attributs de données correspondants. Les données d'entrée de l'ajustement peuvent être chargées à partir d'Excel, d'une base de données ou même d'une source de données personnalisée telle qu'un document Word (en étendant l'attribut de données de base). Cela vous permet de tirer parti d'une plate-forme de test unique pour les tests unitaires et les tests d'intégration, ce qui peut être énorme pour réduire les dépendances entre les produits et la formation requise.

D'autres approches des tests peuvent également être mises en œuvre avec xUnit.NET... les possibilités sont assez illimitées. Combiné avec un autre cadre de simulation très prometteur, Moq Ces deux éléments constituent une plate-forme très souple, extensible et puissante pour la mise en œuvre de tests automatisés.

Answer 2

NUnit est probablement le plus supporté par les outils tiers. Il existe également depuis plus longtemps que les trois autres.

Personnellement, je ne me soucie guère des cadres de tests unitaires, les bibliothèques de simulacre sont, à mon avis, beaucoup plus importantes (et vous enferment beaucoup plus). Il suffit d'en choisir un et de s'y tenir.

Answer 3

Je n'irais pas avec MSTest. Bien qu'il soit probablement le plus évolutif des frameworks avec Microsoft derrière lui, ce n'est pas la solution la plus flexible. Il ne fonctionnera pas seul sans quelques modifications. Il est donc difficile de l'exécuter sur un serveur de construction autre que TFS sans installer Visual Studio. Le test-runner de Visual Studio est en fait plus lent que Testdriven.Net + n'importe lequel des autres frameworks. Et parce que les versions de ce framework sont liées aux versions de Visual Studio, il y a moins de mises à jour et si vous devez travailler avec un ancien VS, vous êtes lié à un ancien MSTest.

Je ne pense pas que cela ait beaucoup d'importance de savoir lequel des autres frameworks vous utilisez. Il est très facile de passer de l'un à l'autre.

Personnellement, j'utilise XUnit.Net ou NUnit, selon la préférence de mes collègues. NUnit est le plus standard. XUnit.Net est le framework le plus léger.

Answer 4

Comme nous avons maintenant une certaine expérience de MBUnit v3.3 et NUnit 2.5.x, je peux comparer les deux :

• Bien que la sémantique et la syntaxe soient très similaires entre les deux, la conception de l'API de NUnit est moins intuitive. Vous devez savoir quand utiliser Assert.* , StringAssert.* , CollectionAssert.* et parfois des fonctions liées aux chaînes de caractères dans Assert.* . L'ordre des paramètres pour "expected" et "value" est également source de confusion dans NUnit. MBUnit suit le bon sens. Par exemple GreaterThan(value, expected) est plus logique, mais NUnit utilise la convention expected, value qui, en fait, ressemble plus à un LessThan .
• Nous avons constaté qu'il est plus facile de mettre en œuvre des tests GUI avec MBUnit car AssemblyFixture vous permet d'itérer tous les tests sur différents paramètres globaux tels que les "navigateurs web". Dans NUnit, nous devions avoir des fichiers de configuration différents pour chaque navigateur, ce qui était très difficile à gérer.
• Le client GUI de MBUnit, Gallio Icarus, est très gonflé et très lent. Le client GUI de NUnit, quant à lui, manque de nombreuses fonctionnalités (comme le débogage en un seul clic).
• Les temps d'exécution des tests des clients en ligne de commande sont presque les mêmes.
• ReSharper NCrunch test runner est le meilleur environnement, le plus rapide et le plus facile à utiliser pour les deux.
• MBUnit supporte les tests parallélisés. Cela s'avère pratique lorsque vous avez des tests isolés qui ont besoin de Sleep pendant de longues périodes. Pendant ce temps, vous pouvez exécuter d'autres tests non pertinents en parallèle, ce qui réduit considérablement le temps d'exécution.
• Il existe une relation d'amour et de haine entre MBUnit et ReSharper. R# ne supporte pas MBUnit d'emblée, tandis que MBUnit a eu du mal à assurer la compatibilité de son propre plugin R#. Nous avons vu de nombreuses régressions sérieuses dans les versions de MBUnit, mais NUnit a toujours conservé des versions assez stables. Note : Je suggère fortement d'utiliser NCrunch au lieu de R# pour le développement de tests MBUnit. C'est génial et gratuit jusqu'à présent . (Je crois toujours que NCrunch vaut l'argent)
• Le support des tests générationnels de NUnit, bien que s'améliorant rapidement, n'a pas encore rattrapé celui de MBUnit. Vous ne pouvez pas alimenter vos tests à partir de membres non statiques par exemple, ce qui est possible dans MBUnit. NUnit ne supporte pas non plus les jointures en paires pour les combinaisons.
• MBUnit semble plus indulgent lorsqu'il s'agit du placement des attributs. Vous pouvez mettre un Column avant la déclaration de la fonction et MBUnit suppose qu'il appartient au premier paramètre de la fonction. NUnit exige strictement que vous les placiez aux bons endroits. Ce n'est pas nécessairement bon ou mauvais, mais c'est juste quelque chose que nous avons découvert pendant nos tests de changement.
• NUnit manque StructuralEqualityComparer ce qui vous fait gagner du temps pour implémenter des comparateurs d'objets afin d'obtenir une comparaison par valeur pour les assertions. Il n'y a pas de moyen plus court de le faire dans NUnit, à part écrire des comparateurs de test uniquement pour vos classes, ce qui est plus difficile.
• NUnit n'a pas d'équivalent de Assert.ForAll . Vous devez faire un foreach(...) Assert.xxx à la place.
• Pour ce que ça vaut, MBUnit a un support pour exécuter des tests d'autres frameworks dans son propre runner. Je n'en ai jamais eu besoin et je ne sais pas qui en aurait besoin. Pourtant, c'est là.

Dans l'ensemble, je trouve MBUnit plus facile à utiliser, plus intuitif. Je suis également heureux que NUnit adopte rapidement des idées éprouvées et réussies sur différents frameworks. J'espère que NUnit pourra rattraper son retard et que nous pourrons bénéficier de la concurrence.

Answer 5

Envisagez de compléter, et non de remplacer, MSTest par un autre cadre de test. Vous pouvez conserver l'intégration de Visual Studio MSTest tout en bénéficiant des avantages d'un cadre de test plus complet.

Par exemple, j'utilise xUnit avec MSTest. Ajoutez une référence à l'assemblage xUnit.dll, et faites quelque chose comme ceci. Etonnamment, ça marche !

using Microsoft.VisualStudio.TestTools.UnitTesting;
using Assert = Xunit.Assert;  // <-- Aliasing the Xunit namespace is key

namespace TestSample
{
    [TestClass]
    public class XunitTestIntegrationSample
    {
        [TestMethod]
        public void TrueTest()
        {
            Assert.True(true);  // <-- this is the Xunit.Assert class
        }

        [TestMethod]
        public void FalseTest()
        {
            Assert.False(true);
        }
    }
}