Ordre d'exécution des tests NUnit


110

Par défaut, les tests des unités sont exécutés par ordre alphabétique. Quelqu'un connaît-il un moyen de définir l'ordre d'exécution? Existe-t-il un attribut pour cela?


7
Pourquoi voudriez-vous faire ça? Il semble que vous ayez une dépendance sur l'ordre d'exécution, ce qui est une mauvaise chose. Vous devez reconsidérer pourquoi vous voulez cela. Les tests unitaires doivent s'exécuter de manière isolée et être totalement indépendants des autres. Il semble que vous créez des candidats pour les tests d'odeur erratique de test .
RichardOD

Cela ressemble à un doublon, mais vous pouvez voir ma réponse ici
Johnno Nolan

12
@RichardOD - devrait! = Doit. Et ce n'est vraiment pas un événement incontournable, car en fait presque tous les tests d'intégration sont exécutés dans l'ordre - demandez à votre équipe d'assurance qualité si elle aléatoirement l'ordre de ses tests.
tymtam

4
J'ai actuellement des tests dont l'ordre semble avoir de l'importance même si cela ne devrait pas. Personnellement, j'aimerais un moyen de randomiser l'ordre de test spécifiquement pour m'aider à m'assurer que mes tests NE SONT PAS en quelque sorte dépendant de l'ordre. Bien sûr, ce que je voudrais VRAIMENT, ce serait un testeur qui exécuterait tous mes tests dans un ordre aléatoire jusqu'à ce qu'il trouve un problème, ou je dis stop. Si je courais cela pendant la nuit et que tout était encore vert le matin, alors je pourrais être sûr que j'ai éliminé le dernier des effets secondaires involontaires.
Mel

1
cette question serait rendue plus pertinente si la question était mise à jour pour spécifier que nous parlons de tests d'intégration ici ... Nous connaissons tous les règles sur les tests unitaires, du moins si vous avez lu les modèles de test XUnit et suivi Oncle Bob etc. vous le faites ... mais les frameworks tels que NUnit sont également très utiles pour que les tests d'intégration soient également opérationnels rapidement ... et vous ne voulez certainement pas qu'ils soient aléatoires, surtout quand une configuration de base de données coûteuse est impliquée ..
nrjohnstone

Réponses:


51

Vos tests unitaires doivent chacun pouvoir s'exécuter indépendamment et de manière autonome. S'ils satisfont à ce critère, l'ordre n'a pas d'importance.

Il y a des occasions cependant où vous voudrez exécuter certains tests en premier. Un exemple typique est dans une situation d'intégration continue où certains tests durent plus longtemps que d'autres. Nous utilisons l'attribut category pour pouvoir exécuter les tests qui utilisent le mocking avant les tests qui utilisent la base de données.

ie mettez ceci au début de vos tests rapides

[Category("QuickTests")]

Lorsque vous avez des tests qui dépendent de certaines conditions environnementales, considérez les attributs TestFixtureSetUp et TestFixtureTearDown , qui vous permettent de marquer les méthodes à exécuter avant et après vos tests.


2
@Chris, j'ai tendance à ne pas utiliser ces attributs, c'est un article de blog intéressant - jamesnewkirk.typepad.com/posts/2007/09/why-you-should-.html . Bon point sur les tests de catégorie cependant.
RichardOD

29
Un autre exemple de tests dépendants de l'ordre est lorsque vous souhaitez utiliser votre framework nunit pour exécuter un test d'intégration ...
Byron Ross

1
@ByronRoss: J'ai tendance à agrandir les tests lorsque je fais cela, et à m'appuyer le plus possible sur les tests unitaires existants pour pouvoir écrire moins de tests. Ensuite, chaque exécution complète peut échouer séparément. J'essaie également de concevoir mes données de manière à ce qu'elles puissent vivre séparément des données existantes, plutôt que de dépendre des données existantes.
Merlyn Morgan-Graham

1
Si vous n'exécutez pas vos tests dans un ordre aléatoire, comment pouvez-vous vérifier qu'ils fonctionnent réellement lorsqu'ils sont en panne? Ce que vous dites équivaut à dire "Si votre logiciel ne présente aucun bogue, les tests ne sont pas nécessaires".
jforberg le

@jforberg: Si vous avez un échec qui se produit au hasard, comment dites-vous quand vous l'avez corrigé?
NeedHack

175

Je tiens simplement à souligner que si la plupart des répondants ont supposé qu'il s'agissait de tests unitaires, la question ne précisait pas qu'ils l'étaient.

nUnit est un excellent outil qui peut être utilisé pour une variété de situations de test. Je peux voir les raisons appropriées pour vouloir contrôler l'ordre de test.

Dans ces situations, j'ai dû recourir à l'incorporation d'un ordre d'exécution dans le nom du test. Ce serait formidable de pouvoir spécifier l'ordre d'exécution à l'aide d'un attribut.


Vous voulez dire que vous avez appelé vos tests, par exemple, 001_first_test 002_second_testet ainsi de suite?
ashes999

Oui, c'est vrai, même si j'utilise typiquement un motif qui me permet d'insérer facilement des tests si nécessaire, donc peut-être 010_first_test, 020_second_test, etc.
Les

83
Merci pour la seule réponse sensée ici. C'est une question spécifique, mais des réponses pédantes vagues sont en quelque sorte votées. Oui, nous savons tous ce que devraient être les tests unitaires, mais ce n'est pas la question.
Egor Pavlikhin

1
Vous ne devez pas vous fier à l'ordre d'exécution alphabétique. De nombreux testeurs exécutent vos tests simultanément sur de nombreux threads ou processus et pas nécessairement par ordre alphabétique. Par exemple, NCrunch priorise les tests en fonction du code que vous modifiez (tests impactés), puis en fonction de leur échec la dernière fois, puis de leur exécution rapide ou lente. Si vous voulez un ordre défini , créez simplement un méta-runner pour ces tests et excluez-les des exécutions régulières.
Abel du

3
Une autre bonne raison de spécifier l'ordre est d'attraper certains problèmes avant de continuer avec le reste de la suite de tests. en d'autres termes, si mon test pour créer un utilisateur échoue, je n'ai pas besoin de tout le reste à exécuter avant de découvrir ce résultat. Dans mon autre test, je me moque probablement de l'utilisateur, mais il est important pour moi que ce soit le premier test à échouer - en particulier lorsque la suite de tests est grande.
Bron Davies le

125

NUnit 3.2.0 a ajouté un OrderAttribute, voir:

https://github.com/nunit/docs/wiki/Order-Attribute

Exemple:

public class MyFixture
{
    [Test, Order(1)]
    public void TestA() { ... }


    [Test, Order(2)]
    public void TestB() { ... }

    [Test]
    public void TestC() { ... }
}

5
Merci, exactement ce que je cherchais - et pas de discussions, pourquoi c'est bon ou mauvais :)
aknoepfel

1
Et puis ils en font un entier, au lieu de décimal, donc si l'on doit insérer un test, tous les tests doivent être renumérotés.
epitka

Vous pouvez toujours commencer avec de très grands nombres comme des millions ou quelque chose du genre si vous souhaitez introduire des éléments intermédiaires de cette façon - juste plus de frappe. Je pense qu'il devrait y avoir un moyen plus simple d'ordonner les choses que d'utiliser des nombres pour la priorité comme un arbre de dépendance de méthode, mais chacun a ses propres inconvénients.
Răzvan Flavius ​​Panda

9
Bonne réponse, mais attention, la documentation indique que les tests n'attendent pas la fin des tests préalables.
ROX

Fait intéressant, d'après mon expérience, si nous ajoutons séparément les attributs Test et Order, il n'y a aucune garantie de commande des tests.
AT

22

Vouloir que les tests s'exécutent dans un ordre spécifique ne signifie pas que les tests sont dépendants les uns des autres - je travaille sur un projet TDD en ce moment, et étant un bon TDDer, je me suis moqué / écrasé de tout, mais cela ferait il est plus lisible si je pouvais spécifier l'ordre dans lequel les résultats des tests sont affichés - par thème plutôt que par ordre alphabétique. Jusqu'à présent, la seule chose à laquelle je puisse penser est d'ajouter a_ b_ c_ aux classes aux classes, aux espaces de noms et aux méthodes. (Pas sympa) Je pense qu'un attribut [TestOrderAttribute] serait bien - pas strictement suivi par le framework, mais un indice pour que nous puissions y parvenir


10

Indépendamment du fait que les tests dépendent ou non de l'ordre ... certains d'entre nous veulent simplement tout contrôler, de manière ordonnée.

Les tests unitaires sont généralement créés par ordre de complexité. Alors, pourquoi ne devraient-ils pas également être exécutés par ordre de complexité ou dans l'ordre dans lequel ils ont été créés?

Personnellement, j'aime voir les tests se dérouler dans l'ordre dans lequel je les ai créés. Dans TDD, chaque test successif sera naturellement plus complexe et prendra plus de temps à s'exécuter. Je préférerais voir le test plus simple échouer en premier car ce sera un meilleur indicateur de la cause de l'échec.

Mais, je peux aussi voir l'avantage de les exécuter dans un ordre aléatoire, surtout si vous voulez tester que vos tests n'ont aucune dépendance avec d'autres tests. Que diriez-vous d'ajouter une option pour tester les coureurs à "Exécuter les tests de manière aléatoire jusqu'à l'arrêt"?


9

Je teste avec Selenium sur un site web assez complexe et toute la suite de tests peut durer plus d'une demi-heure, et je ne suis pas encore près de couvrir toute l'application. Si je dois m'assurer que tous les formulaires précédents sont correctement remplis pour chaque test, cela ajoute beaucoup de temps, et pas seulement une petite quantité de temps, au test global. S'il y a trop de frais généraux à exécuter les tests, les gens ne les exécuteront pas aussi souvent qu'ils le devraient.

Donc, je les mets en ordre et je dépends des tests précédents pour avoir des zones de texte et autres complétés. J'utilise Assert.Ignore () lorsque les pré-conditions ne sont pas valides, mais je dois les faire fonctionner dans l'ordre.


1
Totalement. Je suis dans le même bateau ici.
Sleeper Smith

Moi aussi! Exactement pourquoi j'ai atterri sur cette question!
Niklas Wulff

@NiklasRingdahl si vous utilisez Visual Studio avec nunit, videz nunit et utilisez des tests MS. Ensuite, vous pouvez utiliser le fichier de test ordonné de Visual Studio pour organiser les cas de test dans l'ordre dans lequel vous voulez qu'ils soient exécutés
Rahul Lodha

@RahulLodha Merci! J'examinerai cela.
Niklas Wulff

9

J'aime vraiment la réponse précédente.

Je l'ai un peu changé pour pouvoir utiliser un attribut pour définir la plage de commande:

namespace SmiMobile.Web.Selenium.Tests
{
    using System;
    using System.Collections.Generic;
    using System.Linq;
    using System.Reflection;
    using NUnit.Framework;

    public class OrderedTestAttribute : Attribute
    {
        public int Order { get; set; }


        public OrderedTestAttribute(int order)
        {
            Order = order;
        }
    }

    public class TestStructure
    {
        public Action Test;
    }

    class Int
    {
        public int I;
    }

    [TestFixture]
    public class ControllingTestOrder
    {
        private static readonly Int MyInt = new Int();

        [TestFixtureSetUp]
        public void SetUp()
        {
            MyInt.I = 0;
        }

        [OrderedTest(0)]
        public void Test0()
        {
            Console.WriteLine("This is test zero");
            Assert.That(MyInt.I, Is.EqualTo(0));
        }

        [OrderedTest(2)]
        public void ATest0()
        {
            Console.WriteLine("This is test two");
            MyInt.I++; Assert.That(MyInt.I, Is.EqualTo(2));
        }


        [OrderedTest(1)]
        public void BTest0()
        {
            Console.WriteLine("This is test one");
            MyInt.I++; Assert.That(MyInt.I, Is.EqualTo(1));
        }

        [OrderedTest(3)]
        public void AAA()
        {
            Console.WriteLine("This is test three");
            MyInt.I++; Assert.That(MyInt.I, Is.EqualTo(3));
        }


        [TestCaseSource(sourceName: "TestSource")]
        public void MyTest(TestStructure test)
        {
            test.Test();
        }

        public IEnumerable<TestCaseData> TestSource
        {
            get
            {
                var assembly =Assembly.GetExecutingAssembly();
                Dictionary<int, List<MethodInfo>> methods = assembly
                    .GetTypes()
                    .SelectMany(x => x.GetMethods())
                    .Where(y => y.GetCustomAttributes().OfType<OrderedTestAttribute>().Any())
                    .GroupBy(z => z.GetCustomAttribute<OrderedTestAttribute>().Order)
                    .ToDictionary(gdc => gdc.Key, gdc => gdc.ToList());

                foreach (var order in methods.Keys.OrderBy(x => x))
                {
                    foreach (var methodInfo in methods[order])
                    {
                        MethodInfo info = methodInfo;
                        yield return new TestCaseData(
                            new TestStructure
                                {
                                    Test = () =>
                                        {
                                            object classInstance = Activator.CreateInstance(info.DeclaringType, null);
                                            info.Invoke(classInstance, null);
                                        }
                                }).SetName(methodInfo.Name);
                    }
                }

            }
        }
    }
}

Je pense que cette approche est excellente. Notez cependant que le code de réflexion va extraire toutes les méthodes avec l'attribut, donc si vous essayez d'exécuter un montage de test spécifique, vous serez peut-être surpris de constater qu'il s'exécute plus que vous ne le pensiez. Vous pouvez facilement modifier la requête LINQ si ce n'est pas le comportement souhaité. Voir les liens dans ma réponse pour plus d'informations.
Chrispy

OrderedTestn'est plus pris en charge dans NUnit 3.
Conrad

7

Je sais que c'est un article relativement ancien, mais voici une autre façon de garder votre test dans l'ordre SANS rendre les noms de test gênants. En utilisant l'attribut TestCaseSource et en faisant en sorte que l'objet que vous transmettez ait un délégué (Action), vous pouvez totalement non seulement contrôler l'ordre, mais également nommer le test ce qu'il est.

Cela fonctionne car, selon la documentation, les éléments de la collection renvoyés par la source de test s'exécuteront toujours dans l'ordre dans lequel ils sont répertoriés.

Voici une démo d'une présentation que je donne demain:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using NUnit.Framework;

namespace NUnitTest
{
    public class TestStructure
    {
        public Action Test;
    }

    class Int
    {
        public int I;
    }

    [TestFixture]
    public class ControllingTestOrder
    {
        private static readonly Int MyInt= new Int();

        [TestFixtureSetUp]
        public void SetUp()
        {
            MyInt.I = 0;
        }

        [TestCaseSource(sourceName: "TestSource")]
        public void MyTest(TestStructure test)
        {
            test.Test();
        }

        public IEnumerable<TestCaseData> TestSource
        {
            get
            {
                yield return new TestCaseData(
                    new TestStructure
                    {
                        Test = () =>
                        {
                            Console.WriteLine("This is test one");
                            MyInt.I++; Assert.That(MyInt.I, Is.EqualTo(1));
                        }
                    }).SetName(@"Test One");
                yield return new TestCaseData(
                    new TestStructure
                    {
                        Test = () =>
                        {
                            Console.WriteLine("This is test two");
                            MyInt.I++; Assert.That(MyInt.I, Is.EqualTo(2));
                        }
                    }).SetName(@"Test Two");
                yield return new TestCaseData(
                    new TestStructure
                    {
                        Test = () =>
                        {
                            Console.WriteLine("This is test three");
                            MyInt.I++; Assert.That(MyInt.I, Is.EqualTo(3));
                        }
                    }).SetName(@"Test Three");
            }
        }
    }
}

J'utilise ce modèle pour des tests d'intégration en parallèle qui prendraient trop de temps pour s'exécuter de manière linéaire. Tous les tests sont sur un seul type donc j'utilise une Action <T in>, et chaque Action a une clé qui dit ce que fait "ShouldBeFoo". De cette façon, ce que fait le test sera visible dans le nom du test, et TestCaseSource peut être filtré afin que différents types de tests soient regroupés. Ironiquement, je me fiche de l'ordre d'exécution, mais je suis d'accord pour dire que cela fonctionnerait.
Novaterata

Utiliser le TestCaseSourcecomme moyen d'exécuter des tests ordonnés est un coup de génie. Bien joué. J'ai adopté cette approche avec celle ci-dessous et ajouté quelques modifications supplémentaires pour la rendre plus facile à utiliser. Voir les liens dans ma réponse pour plus d'informations, mais l'idée sous-jacente vient de cette excellente réponse!
Chrispy

Malheureusement, avec NUnit 3, la source de TestCaseSourcedoit être statique, ce qui empêche l'utilisation de pattern. Dommage.
Conrad

@Conrad. Je ne vois pas quelle différence cela fait de rendre la méthode statique ou non. Le test revient toujours dans l'ordre de toute façon.
Dave Bush

Ce n'est pas la méthode qui doit être statique - la source (variable ou propriété) de TestCaseSourcedoit être un objet statique dans NUnit 3, sinon les tests ne s'exécuteront pas. Et vous ne pouvez pas créer d'objets dynamiques dans un objet statique. C'est pourquoi cela ne fonctionnera pas dans la v.3.
Conrad

5

Je travaille avec des cas de test d'interface utilisateur de bout en bout Selenium WebDriver écrits en C #, qui sont exécutés à l'aide du framework NUnit. (Pas de cas unitaires en tant que tels)

Ces tests d'interface utilisateur dépendent certainement de l'ordre d'exécution, car d'autres tests doivent ajouter des données comme condition préalable. (Il n'est pas possible de suivre les étapes de chaque test)

Maintenant, après avoir ajouté le 10ème cas de test, je vois que NUnit veut s'exécuter dans cet ordre: Test_1 Test_10 Test_2 Test_3 ..

Donc je suppose que je dois trop alphabétiser les noms des cas de test pour l'instant, mais il serait bon d'avoir cette petite fonctionnalité de contrôle de l'ordre d'exécution ajoutée à NUnit.


9
Pas d'accord avec Arran: les tests d'interface utilisateur sont intrinsèquement des séquences de petites étapes. Chaque étape doit être un test (Raison - si elle échoue, j'ai besoin de savoir quelle étape). Les séquences peuvent être indépendantes, mais dans une séquence, l'ordre compte et l'arrêt en cas d'échec est nécessaire.
Zasz

3

Généralement, le test unitaire doit être indépendant, mais si vous le devez, vous pouvez nommer vos méthodes par ordre alphabétique, par exemple:

[Test]
public void Add_Users(){}

[Test]
public void Add_UsersB(){}

[Test]
public void Process_Users(){}

ou vous pouvez le faire ..

        private void Add_Users(){}

        private void Add_UsersB(){}

        [Test]
        public void Process_Users()
        {
           Add_Users();
           Add_UsersB();
           // more code
        }

2
Sauf que maintenant, les noms doivent être classés par ordre alphabétique, ce qui est une terrible solution. :(

@ user166390 - non ce n'est pas horrible. Cela fonctionne et dépend du comportement documenté de NUnit.
tymtam

➕1 assez bien pour moi, beaucoup plus facile si vous commencez vos tests avec a_ b_ t1_, à la t2_place ou si vous comptez sur des personnages de fin faciles à manquer
Chris Marisic

3

Il existe de très bonnes raisons d'utiliser un mécanisme de commande de test. La plupart de mes propres tests utilisent de bonnes pratiques telles que la configuration / le démontage. D'autres nécessitent d'énormes quantités de configuration de données, qui peuvent ensuite être utilisées pour tester une gamme de fonctionnalités. Jusqu'à présent, j'ai utilisé de gros tests pour gérer ces tests d'intégration (Selenium Webdriver). Cependant, je pense que le post suggéré ci-dessus sur https://github.com/nunit/docs/wiki/Order-Attribute a beaucoup de mérite. Voici un exemple de pourquoi la commande serait extrêmement précieuse:

  • Utilisation de Selenium Webdriver pour exécuter un test afin de télécharger un rapport
  • L'état du rapport (qu'il soit téléchargeable ou non) est mis en cache pendant 10 minutes
  • Cela signifie qu'avant chaque test, je dois réinitialiser l'état du rapport, puis attendre jusqu'à 10 minutes avant que l'état ne soit confirmé comme ayant changé, puis vérifier le téléchargement du rapport correctement.
  • Les rapports ne peuvent pas être générés de manière pratique / opportune par moquerie ou tout autre mécanisme dans le cadre de test en raison de leur complexité.

Ce temps d'attente de 10 minutes ralentit la suite de tests. Lorsque vous multipliez des délais de mise en cache similaires sur une multitude de tests, cela prend beaucoup de temps. L'ordonnancement des tests pourrait permettre de configurer les données en tant que «test» dès le début de la suite de tests, les tests reposant sur le buste du cache étant exécutés vers la fin du test.


2

Cette question est vraiment ancienne maintenant, mais pour les personnes qui peuvent y accéder en recherchant, j'ai pris les excellentes réponses de user3275462 et PvtVandals / Rico et les ai ajoutées à un référentiel GitHub avec certaines de mes propres mises à jour. J'ai également créé un article de blog associé avec des informations supplémentaires que vous pouvez consulter pour plus d'informations.

J'espère que cela vous sera utile à tous. De plus, j'aime souvent utiliser l'attribut Category pour différencier mes tests d'intégration ou d'autres tests de bout en bout de mes tests unitaires réels. D'autres ont souligné que les tests unitaires ne devraient pas avoir de dépendance d'ordre, mais que d'autres types de tests le font souvent, donc cela fournit un moyen agréable d'exécuter uniquement la catégorie de tests que vous souhaitez et de classer ces tests de bout en bout.


pouvez-vous m'aider avec un problème que j'ai, voici le lien: stackoverflow.com/questions/31281395/…
Morgan Soren

1

Je suis surpris que la communauté NUnit n'ait rien proposé, alors je suis allé créer quelque chose comme ça moi-même.

Je développe actuellement une bibliothèque open-source qui vous permet de commander vos tests avec NUnit. Vous pouvez commander des appareils de test et commander des «spécifications de test ordonnées» de la même manière.

La bibliothèque offre les fonctionnalités suivantes:

  • Créer des hiérarchies complexes de classement des tests
  • Ignorer les tests suivants si un test dans l'ordre échoue
  • Ordonnez vos méthodes de test par dépendance plutôt que par ordre entier
  • Prend en charge l'utilisation côte à côte avec des tests non ordonnés. Les tests non ordonnés sont exécutés en premier.

La bibliothèque est en fait inspirée de la façon dont MSTest teste l'ordre des .orderedtestfichiers. Veuillez regarder un exemple ci-dessous.

[OrderedTestFixture]
public sealed class MyOrderedTestFixture : TestOrderingSpecification {
    protected override void DefineTestOrdering() {
        TestFixture<Fixture1>();

        OrderedTestSpecification<MyOtherOrderedTestFixture>();

        TestFixture<Fixture2>();
        TestFixture<Fixture3>();
    }

    protected override bool ContinueOnError => false; // Or true, if you want to continue even if a child test fails
}

1

Si vous utilisez [TestCase], l'argument TestNamefournit un nom pour le test.

S'il n'est pas spécifié, un nom est généré en fonction du nom de la méthode et des arguments fournis.

Vous pouvez contrôler l'ordre d'exécution des tests comme indiqué ci-dessous:

                    [Test]
            [TestCase("value1", TestName = "ExpressionTest_1")]
            [TestCase("value2", TestName = "ExpressionTest_2")]
            [TestCase("value3", TestName = "ExpressionTest_3")]
            public void ExpressionTest(string  v)
            {
                //do your stuff
            }

Ici, j'ai utilisé le "ExpressionTest"suffixe du nom de la méthode avec un nombre.

Vous pouvez utiliser tous les noms classés par ordre alphabétique, voir Attribut TestCase


0

Vous ne devez pas dépendre de l'ordre dans lequel le framework de test sélectionne les tests à exécuter. Les tests doivent être isolés et indépendants. En cela, ils ne devraient pas dépendre d'un autre test préparant le terrain pour eux ou nettoyant après eux. Ils doivent également produire le même résultat quel que soit l'ordre d'exécution des tests (pour un instantané donné du SUT)

J'ai fait un peu de recherche sur Google. Comme d'habitude, certaines personnes ont eu recours à des astuces sournoises (au lieu de résoudre le problème de testabilité / conception sous-jacent

  • nommer les tests dans l'ordre alphabétique de sorte que les tests apparaissent dans l'ordre où ils «doivent» être exécutés. Cependant, NUnit peut choisir de changer ce comportement avec une version ultérieure et vos tests seront ensuite arrosés. Mieux vaut archiver les binaires NUnit actuels dans le contrôle de code source.
  • VS (IMHO encourageant le mauvais comportement avec leurs «outils agiles») a quelque chose appelé «tests ordonnés» dans leur cadre de test MS. Je n'ai pas perdu de temps à lire mais il semble cibler le même public

Voir aussi: caractéristiques d'un bon test


Il y a des occasions où vous souhaitez que les tests s'exécutent plus rapidement avant de longs tests, en particulier dans les tests d'intégration et d'acceptation. Par exemple, dans une application de blog: vous testez d'abord la connexion, car si cette fonctionnalité ne fonctionne pas, la publication ne fonctionnera pas non plus, il est donc inutile d'exécuter ce test (vous pouvez arrêter le coureur manuellement). Mais si vous essayez de continuer à exécuter des tests, cela prendra plus de temps.
Marcel Valdez Orozco

@MarcelValdezOrozco - vous pouvez atteindre cet objectif en partitionnant vos tests via différentes DLL physiques ou en utilisant des balises / catégories. Vous pouvez créer vos scripts de construction pour exécuter les dll / catégories dans l'ordre. En général, autoriser l'ordre des tests conduit généralement à des tests couplés qui développent des dépendances sur les tests voisins (au fil du temps bien sûr). AFAIR dans la prochaine grande version de NUnit, il va supporter différents ordres de tests, par exemple aléatoires, etc.
Gishu

2
Partitionner davantage le même type de tests (tests d'acceptation, par exemple) n'a aucun sens, et les séparer dans une autre DLL augmente inutilement la complexité partout: code source, scripts de construction, scripts de test, structure de projet, etc. Juste pour faire une simple réorganisation de les tests.
Marcel Valdez Orozco

L'émission (donc fondamentalement toutes les bibliothèques moqueuses) est une raison pour laquelle l'ordre serait important. Vous ne pouvez pas décharger votre domaine d'application, et le runner nunit (s'il exécute tous les tests dans un assembly) conserve ce domaine pour tous les tests dans au moins cette `` correction ''. Si un test crée un type pour tester quelque chose et qu'un autre test entre en conflit avec ce type créé, en raison de l'ordre, ce n'est pas un test défectueux. Ils sont isolés logiquement, c'est juste que nUnit ne fournit pas une isolation appropriée entre chaque «test» lui-même.
Kelly Elton

6
C'est une réponse assez condescendante et cela la rend drôle car elle ne s'applique vraiment qu'aux tests unitaires et ignore complètement le fait d'être pragmatique.
tymtam

0

En cas d'utilisation de TestCaseSourcela clé est la override string ToStringméthode, comment cela fonctionne:

Supposons que vous ayez la classe TestCase

public class TestCase
{
    public string Name { get; set; }
    public int Input { get; set; }
    public int Expected { get; set; }
}

Et une liste de TestCases:

private static IEnumerable<TestCase> TestSource()
{
    return new List<TestCase>
    {
        new TestCase()
        {
           Name = "Test 1",
           Input = 2,
           Expected = 4
        },
        new TestCase()
        {
            Name = "Test 2",
            Input = 4,
            Expected = 16
        },
        new TestCase()
        {
            Name = "Test 3",
            Input = 10,
            Expected = 100
        }
    };
}

Maintenant, utilisons-le avec une méthode de test et voyons ce qui se passe:

[TestCaseSource(nameof(TestSource))]
public void MethodXTest(TestCase testCase)
{
    var x = Power(testCase.Input);
    x.ShouldBe(testCase.Expected);
}

Cela ne testera pas dans l'ordre et la sortie sera comme ceci:

entrez la description de l'image ici

Donc, si nous avons ajouté override string ToStringà notre classe comme:

public class TestCase
{
    public string Name { get; set; }
    public int Input { get; set; }
    public int Expected { get; set; }

    public override string ToString()
    {
        return Name;
    }
}

Le résultat va changer et nous obtenons l'ordre et le nom du test comme:

entrez la description de l'image ici

Remarque:

  1. Ceci est juste un exemple pour illustrer comment obtenir le nom et l'ordre dans le test, l'ordre est pris numériquement / alphabétiquement, donc si vous avez plus de dix tests, je suggère de faire le test 01, le test 02 .... le test 10, le test 11, etc. car si vous faites le test 1 et à un moment donné le test 10, l'ordre sera le test 1, le test 10, le test 2 .. etc.
  2. L'entrée et attendue peuvent être n'importe quel type, chaîne, objet ou classe personnalisée.
  3. À côté de l'ordre, la bonne chose ici est que vous voyez le nom du test qui est le plus important.
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.