Ordine di esecuzione test NUnit


110

Per impostazione predefinita, i test nunit vengono eseguiti in ordine alfabetico. Qualcuno sa come impostare l'ordine di esecuzione? Esiste un attributo per questo?


7
Perché dovresti farlo? Sembra che tu abbia una dipendenza dall'ordine di esecuzione, il che è una cosa negativa. Devi riconsiderare il motivo per cui lo desideri. I test unitari dovrebbero essere eseguiti isolatamente ed essere totalmente indipendenti dagli altri. Sembra che tu stia creando candidati per il test Odore Erratic Tests .
RichardOD

Sembra un duplicato ma puoi vedere la mia risposta qui
Johnno Nolan

12
@RichardOD - dovrebbe! = Deve. E in realtà non è un caso, perché in realtà quasi tutti i test di integrazione vengono eseguiti in ordine: chiedi al tuo team QA se randomizzano l'ordine dei loro test.
tymtam

4
Al momento ho alcuni test il cui ordine sembra essere importante anche se non dovrebbe. Personalmente, mi piacerebbe un modo per randomizzare l'ordine dei test in modo specifico per aiutarmi a garantire che i miei test NON siano in qualche modo dipendenti dall'ordine. Ovviamente, quello che mi piacerebbe VERAMENTE sarebbe un test runner che eseguisse tutti i miei test in ordine casuale fino a quando non trova un problema, o dico stop. Se lo facessi durante la notte e tutto fosse ancora verde al mattino, potrei essere sicuro di aver eliminato l'ultimo degli effetti collaterali indesiderati.
Mel

1
questa domanda sarebbe resa più pertinente se la domanda fosse aggiornata per specificare che stiamo parlando di test di integrazione qui ... Conosciamo tutti le regole sugli unit test, almeno se hai letto i modelli di test di XUnit e hai seguito lo zio Bob ecc .. lo fai .. ma framework come NUnit sono anche molto utili per far funzionare rapidamente i test di integrazione .. e sicuramente non vuoi che siano casuali, specialmente quando è coinvolta una costosa configurazione del database ..
nrjohnstone

Risposte:


51

Ciascuno dei tuoi unit test dovrebbe essere in grado di essere eseguito in modo indipendente e autonomo. Se soddisfano questo criterio, l'ordine non ha importanza.

Tuttavia, ci sono occasioni in cui vorresti prima eseguire determinati test. Un tipico esempio è in una situazione di integrazione continua in cui alcuni test sono più in esecuzione di altri. Usiamo l'attributo category in modo da poter eseguire i test che usano il mocking prima dei test che usano il database.

cioè mettilo all'inizio dei tuoi test rapidi

[Category("QuickTests")]

Se sono presenti test che dipendono da determinate condizioni ambientali, considera gli attributi TestFixtureSetUp e TestFixtureTearDown , che consentono di contrassegnare i metodi da eseguire prima e dopo i test.


2
@ Chris, tendo a non usare questi attributi, questo è un post del blog interessante: jamesnewkirk.typepad.com/posts/2007/09/why-you-should-.html . Un bel punto sui test di categoria però.
RichardOD

29
Un altro esempio di test dipendenti dall'ordine è quando si desidera utilizzare il framework nunit per eseguire un test di integrazione ...
Byron Ross

1
@ByronRoss: tendo a rendere i test più grandi quando lo faccio e mi appoggio il più possibile agli unit test esistenti in modo da poter scrivere meno test. Quindi ogni esecuzione completa può fallire separatamente. Cerco anche di progettare i miei dati in modo che possano vivere separatamente dai dati esistenti, piuttosto che dipendere dai dati esistenti.
Merlyn Morgan-Graham

1
Se non esegui i test in ordine casuale, come puoi verificare che funzionino effettivamente quando sono esauriti? Quello che stai dicendo è analogo a dire "Se il tuo software non ha bug, il test non è necessario".
jforberg

@jforberg: se hai un guasto che si verifica in modo casuale, come si dice quando lo hai risolto?
NeedHack

175

Voglio solo sottolineare che mentre la maggior parte degli intervistati pensava che si trattasse di test unitari, la domanda non specificava che lo fossero.

nUnit è un ottimo strumento che può essere utilizzato per una varietà di situazioni di test. Riesco a vedere le ragioni appropriate per voler controllare l'ordine di prova.

In quelle situazioni ho dovuto ricorrere a incorporare un ordine di esecuzione nel nome del test. Sarebbe fantastico poter specificare l'ordine di esecuzione utilizzando un attributo.


Vuoi dire che hai chiamato i tuoi test, per esempio, 001_first_test 002_second_teste così via?
ceneri999

Sì, è vero, anche se in genere utilizzo uno schema che mi consente di inserire facilmente test se necessario, quindi forse 010_first_test, 020_second_test, ecc.
Les

83
Grazie per l'unica risposta sensata qui. Questa è una domanda specifica, eppure in qualche modo si stanno votando vago risposte vaghe. Sì, sappiamo tutti cosa dovrebbero essere i test unitari, ma non è questo il problema.
Egor Pavlikhin

1
Non dovresti fare affidamento sul fatto che l'ordine di esecuzione sia alfabetico. Molti test runner eseguono i test contemporaneamente su più thread o processi e non necessariamente in ordine alfabetico. Ad esempio, NCrunch assegna la priorità ai test in base al codice modificato (test interessati), quindi se l'ultima volta hanno fallito, quindi se vengono eseguiti rapidamente o lentamente. Se vuoi un ordine definito , crea semplicemente un meta-runner per quei test ed escludili dalle corse regolari.
Abel

3
Un altro buon motivo per specificare l'ordine è rilevare alcuni problemi prima di continuare con il resto della suite di test. in altre parole, se il mio test per creare un utente fallisce, non ho bisogno che tutto il resto venga eseguito prima di scoprire questo risultato. Nell'altro mio test probabilmente prendo in giro l'utente, ma è importante per me che questo sia il primo test a fallire, in particolare quando la suite di test è grande.
Bron Davies

125

NUnit 3.2.0 ha aggiunto un file OrderAttribute , vedere:

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

Esempio:

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


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

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

5
Grazie, dritto al punto quello che stavo cercando - e nessuna discussione, perché è buono o cattivo :)
aknoepfel

1
E poi lo rendono un numero intero, invece che decimale, quindi se si deve inserire test, tutti i test devono essere rinumerati.
epitka

Puoi sempre iniziare con numeri molto grandi come milioni o qualcosa del genere se vuoi introdurre elementi intermedi in questo modo - solo più battitura. Imo dovrebbe esserci un modo più semplice per ordinare le cose che usare i numeri per la priorità come un albero delle dipendenze del metodo, ma ognuno ha i suoi vantaggi.
Răzvan Flavius ​​Panda

9
Buona risposta, ma attenzione, la documentazione afferma che i test non aspettano il termine dei test precedenti.
ROX

È interessante notare che, nella mia esperienza, se aggiungiamo separatamente gli attributi Test e Order, non vi è alcuna garanzia di ordinare i test.
AT

22

Volere che i test vengano eseguiti in un ordine specifico non significa che i test dipendano l'uno dall'altro: al momento sto lavorando a un progetto TDD ed essendo un bravo TDDer ho deriso / stubbato tutto, ma sarebbe è più leggibile se potessi specificare l'ordine di visualizzazione dei risultati dei test - tematicamente invece che alfabeticamente. Finora l'unica cosa a cui posso pensare è anteporre a_ b_ c_ alle classi a classi, spazi dei nomi e metodi. (Non carino) Penso che un attributo [TestOrderAttribute] sarebbe carino - non strettamente seguito dal framework, ma un suggerimento in modo che possiamo ottenere questo risultato


10

Indipendentemente dal fatto che i test dipendano o meno dall'ordine ... alcuni di noi vogliono semplicemente controllare tutto, in modo ordinato.

Gli unit test vengono generalmente creati in ordine di complessità. Quindi, perché non dovrebbero essere eseguiti anche in ordine di complessità o nell'ordine in cui sono stati creati?

Personalmente, mi piace vedere i test eseguiti nell'ordine in cui li ho creati. In TDD, ogni test successivo sarà naturalmente più complesso e richiederà più tempo per essere eseguito. Preferirei vedere il test più semplice fallire prima in quanto sarà un indicatore migliore della causa del fallimento.

Ma posso anche vedere il vantaggio di eseguirli in ordine casuale, soprattutto se vuoi verificare che i tuoi test non abbiano dipendenze da altri test. Che ne dici di aggiungere un'opzione per testare i corridori a "Esegui test in modo casuale fino all'arresto"?


9

Sto testando con Selenium su un sito web abbastanza complesso e l'intera suite di test può essere eseguita per più di mezz'ora, e non sono ancora vicino a coprire l'intera applicazione. Se devo assicurarmi che tutti i moduli precedenti siano compilati correttamente per ogni test, questo aggiunge molto tempo, non solo una piccola quantità di tempo, al test complessivo. Se c'è troppo sovraccarico per eseguire i test, le persone non li eseguiranno tutte le volte che dovrebbero.

Quindi, li metto in ordine e dipendo dai test precedenti per avere caselle di testo e simili completati. Uso Assert.Ignore () quando le pre-condizioni non sono valide, ma ho bisogno che vengano eseguite in ordine.


1
Totalmente. Sono nella stessa barca qui.
Sleeper Smith

Anch'io! Esattamente perché sono arrivato su questa domanda!
Niklas Wulff

@NiklasRingdahl se stai usando Visual Studio con nunit, scarica nunit e usa i test MS. quindi puoi utilizzare il file ordertest di Visual Studio per organizzare i casi di test nell'ordine in cui desideri che vengano eseguiti
Rahul Lodha

@RahulLodha Thanks! Lo esaminerò.
Niklas Wulff

9

Mi piace molto la risposta precedente.

L'ho modificato un po 'per poter utilizzare un attributo per impostare l'intervallo di ordini:

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);
                    }
                }

            }
        }
    }
}

Penso che questo approccio sia fantastico. Nota però che il codice di riflessione estrarrà tutti i metodi con l'attributo, quindi se stai cercando di eseguire un dispositivo di test specifico, potresti essere sorpreso di scoprire che funziona più di quanto pensavi. È possibile modificare facilmente la query LINQ se questo non è il comportamento desiderato. Vedi i link nella mia risposta per maggiori informazioni.
Chrispy

OrderedTestnon è più supportato in NUnit 3.
Conrad

7

So che questo è un post relativamente vecchio, ma ecco un altro modo per mantenere il tuo test in ordine SENZA rendere i nomi dei test imbarazzanti. Utilizzando l'attributo TestCaseSource e facendo in modo che l'oggetto che passi abbia un delegato (Action), puoi non solo controllare totalmente l'ordine, ma anche nominare il test di cosa si tratta.

Questo funziona perché, secondo la documentazione, gli elementi nella raccolta restituiti dall'origine del test verranno sempre eseguiti nell'ordine in cui sono elencati.

Ecco una demo di una presentazione che farò domani:

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");
            }
        }
    }
}

Uso questo modello per i test di integrazione in parallelo che richiederebbero troppo tempo per essere eseguiti in modo lineare. Tutti i test sono su un solo tipo, quindi uso un'azione <T in> e ogni azione ha una chiave che dice cosa fa "ShouldBeFoo". In questo modo ciò che fa il test sarà visibile nel nome del test e TestCaseSource può essere filtrato in modo da raggruppare diversi tipi di test. Ironia della sorte, non mi interessa l'ordine di esecuzione, ma sono d'accordo che funzionerebbe.
Novaterata

Usare il TestCaseSourcecome un modo per eseguire test ordinati è un colpo di genio. Molto bene. Ho adottato questo approccio insieme a quello di seguito e ho aggiunto alcune modifiche aggiuntive per renderlo più facile da usare. Vedi i link nella mia risposta per ulteriori informazioni, ma l'idea di fondo è da questa ottima risposta!
Chrispy

Purtroppo, con NUnit 3, l'origine di TestCaseSourcedeve essere statica, il che preclude l'utilizzo di pattern. Bummer.
Conrad

@Conrad. Non vedo quale differenza faccia o no il metodo statico. Il test torna comunque in ordine in entrambi i casi.
Dave Bush,

Non è il metodo che deve essere statico: la sorgente (variabile o proprietà) di TestCaseSourcedeve essere un oggetto statico in NUnit 3, altrimenti i test non verranno eseguiti. E non puoi creare oggetti dinamici all'interno di un oggetto statico. Ecco perché non funzionerà in v. 3.
Conrad

5

Sto lavorando con i test case dell'interfaccia utente end-to-end Selenium WebDriver scritti in C #, che vengono eseguiti utilizzando il framework NUnit. (Non casi unitari in quanto tali)

Questi test dell'interfaccia utente dipendono certamente dall'ordine di esecuzione, poiché altri test devono aggiungere alcuni dati come condizione preliminare. (Non è possibile eseguire i passaggi in ogni test)

Ora, dopo aver aggiunto il decimo scenario di test, vedo che NUnit vuole essere eseguito in questo ordine: Test_1 Test_10 Test_2 Test_3 ..

Quindi immagino di dover alfabetizzare troppo i nomi dei casi di test per ora, ma sarebbe bene avere questa piccola funzione di controllo dell'ordine di esecuzione aggiunta a NUnit.


9
Non sono d'accordo con Arran: i test dell'interfaccia utente sono intrinsecamente sequenze di piccoli passaggi. Ogni passaggio dovrebbe essere un test (motivo: se fallisce, devo sapere quale passaggio). Le sequenze possono essere indipendenti, ma all'interno di una sequenza l'ordine è importante ed è necessario fermarsi in caso di fallimento.
Zasz

3

Di solito Unit Test dovrebbe essere indipendente, ma se è necessario, è possibile denominare i metodi in ordine alfabetico es:

[Test]
public void Add_Users(){}

[Test]
public void Add_UsersB(){}

[Test]
public void Process_Users(){}

oppure puoi farlo ..

        private void Add_Users(){}

        private void Add_UsersB(){}

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

2
Solo che ora i nomi devono essere resi alfabetici, che è una soluzione orribile. :(

@ user166390 - no, non è orribile. Funziona e dipende dal comportamento documentato di NUnit.
tymtam

➕1 abbastanza buono per me, molto più facile se inizi i tuoi test con a_ b_ t1_, t2_invece o ti affidi a caratteri finali facili da perdere
Chris Marisic

3

Ci sono ottime ragioni per utilizzare un meccanismo di ordinazione dei test. La maggior parte dei miei test utilizza buone pratiche come installazione / smontaggio. Altri richiedono enormi quantità di configurazione dei dati, che possono quindi essere utilizzati per testare una serie di funzionalità. Fino ad ora, ho utilizzato test di grandi dimensioni per gestire questi test di integrazione (Selenium Webdriver). Tuttavia, penso che il post suggerito sopra su https://github.com/nunit/docs/wiki/Order-Attribute abbia molto merito. Ecco un esempio del motivo per cui ordinare sarebbe estremamente prezioso:

  • Utilizzo di Selenium Webdriver per eseguire un test per scaricare un report
  • Lo stato del rapporto (scaricabile o meno) viene memorizzato nella cache per 10 minuti
  • Ciò significa che prima di ogni test è necessario reimpostare lo stato del report e quindi attendere fino a 10 minuti prima che venga confermato che lo stato è cambiato, quindi verificare che il report venga scaricato correttamente.
  • I report non possono essere generati in modo pratico / tempestivo tramite mocking o qualsiasi altro meccanismo all'interno del framework di test a causa della loro complessità.

Questo tempo di attesa di 10 minuti rallenta la suite di test. Quando si moltiplicano ritardi di memorizzazione nella cache simili in una moltitudine di test, si consuma molto tempo. Ordinare i test potrebbe consentire di eseguire la configurazione dei dati come un "Test" all'inizio della suite di test, con i test che si basano sul busting della cache eseguiti verso la fine dell'esecuzione del test.


2

Questa domanda è davvero vecchia ora, ma per le persone che potrebbero raggiungerla dalla ricerca, ho preso le eccellenti risposte da user3275462 e PvtVandals / Rico e le ho aggiunte a un repository GitHub insieme ad alcuni dei miei aggiornamenti. Ho anche creato un post sul blog associato con alcune informazioni aggiuntive che puoi guardare per maggiori informazioni.

Spero che questo sia utile per tutti voi. Inoltre, spesso mi piace utilizzare l'attributo Category per differenziare i miei test di integrazione o altri test end-to-end dai miei unit test effettivi. Altri hanno sottolineato che gli unit test non dovrebbero avere una dipendenza dall'ordine, ma altri tipi di test spesso lo fanno, quindi questo fornisce un bel modo per eseguire solo la categoria di test che desideri e anche ordinare quei test end-to-end.


potete aiutarmi con un problema che ho, ecco il link: stackoverflow.com/questions/31281395/…
Morgan Soren

1

Sono sorpreso che la comunità di NUnit non abbia escogitato nulla, quindi sono andato a creare qualcosa di simile da solo.

Attualmente sto sviluppando una libreria open source che ti consente di ordinare i tuoi test con NUnit. È possibile ordinare apparecchiature di prova e ordinare "specifiche di prova ordinate" allo stesso modo.

La libreria offre le seguenti funzionalità:

  • Crea complesse gerarchie di ordinamento dei test
  • Salta i test successivi se un test in ordine fallisce
  • Ordina i tuoi metodi di prova per dipendenza invece che per numero intero
  • Supporta l'utilizzo fianco a fianco con test non ordinati. I test non ordinati vengono eseguiti per primi.

La libreria è effettivamente ispirata al modo in cui MSTest esegue i test di ordinamento con i .orderedtestfile. Si prega di guardare un esempio di seguito.

[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

Se stai usando [TestCase], l'argomento TestNamefornisce un nome per il test.

Se non specificato, viene generato un nome in base al nome del metodo e agli argomenti forniti.

È possibile controllare l'ordine di esecuzione del test come indicato di seguito:

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

Qui ho usato il "ExpressionTest"suffisso del nome del metodo con un numero.

È possibile utilizzare qualsiasi nome in ordine alfabetico, vedere Attributo TestCase


0

Non dovresti dipendere dall'ordine in cui il framework di test seleziona i test per l'esecuzione.I test dovrebbero essere isolati e indipendenti. In quanto non dovrebbero dipendere da altri test che preparano il terreno per loro o che puliscono dopo di loro. Dovrebbero anche produrre lo stesso risultato indipendentemente dall'ordine di esecuzione dei test (per una data istantanea del SUT)

Ho cercato su Google. Come al solito, alcune persone hanno fatto ricorso a trucchi subdoli (invece di risolvere il problema di testabilità / progettazione sottostante

  • denominare i test in modo ordinato alfabetico in modo che i test appaiano nell'ordine in cui "devono" essere eseguiti. Tuttavia, NUnit può scegliere di modificare questo comportamento con una versione successiva e quindi i tuoi test verranno cancellati. Controllare meglio i binari correnti di NUnit nel controllo del codice sorgente.
  • VS (IMHO incoraggia il comportamento sbagliato con i loro "strumenti agili") ha qualcosa chiamato "test ordinati" nel loro framework di test MS. Non ho perso tempo a leggere ma sembra che sia rivolto allo stesso pubblico

Vedi anche: caratteristiche di un buon test


Ci sono occasioni in cui vorresti che i test fossero eseguiti più velocemente prima dei test a lunga esecuzione, in particolare nei test di integrazione e accettazione. Ad esempio, in un'app di blog: prima verifichi il login, perché se quella funzione non funziona, neanche la pubblicazione funzionerà, quindi non ha senso eseguire quel test (puoi fermare il runner manualmente). Ma se provi a continuare a eseguire i test, ci vorrà più tempo.
Marcel Valdez Orozco

@MarcelValdezOrozco: puoi raggiungere questo obiettivo partizionando i tuoi test tramite dll fisiche diverse o utilizzando tag / categorie. Puoi creare i tuoi script di build per eseguire dll / categorie in ordine. In generale, consentire l'ordinamento dei test di solito porta a test accoppiati che sviluppano dipendenze dai test adiacenti (nel tempo ovviamente). AFAIR nella prossima grande versione di NUnit, supporterà un diverso ordinamento dei test, ad esempio casuale ecc.
Gishu

2
Partizionare ulteriormente lo stesso tipo di test (test di accettazione, ad esempio) non ha senso e separarli in un'altra DLL aumenta inutilmente la complessità ovunque: codice sorgente, script di build, script di test, struttura del progetto, ecc. Solo per fare un semplice riordino di i test.
Marcel Valdez Orozco

Emettere (quindi fondamentalmente tutte le librerie beffarde) sono un motivo per cui l'ordine sarebbe importante. Non è possibile scaricare il dominio dell'app e il runner nunit (se esegue tutti i test in un assembly) mantiene quel dominio per tutti i test almeno in quella "correzione". Se un test crea un tipo per testare qualcosa e un altro test è in conflitto con quel tipo creato, a causa dell'ordine, non è un test difettoso. Sono isolati logicamente, è solo che nUnit non fornisce un isolamento adeguato tra ogni "test" stesso.
Kelly Elton

6
Questa è una risposta piuttosto paternalistica e lo rende divertente perché in realtà si applica solo agli unit test e ignora completamente l'essere pragmatici.
tymtam

0

In caso di utilizzo TestCaseSourcedella chiave è override string ToStringmetodo, come funziona:

Supponi di avere la classe TestCase

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

E un elenco di casi di prova:

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
        }
    };
}

Ora usiamolo con un metodo di test e vediamo cosa succede:

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

Questo non verrà testato in ordine e l'output sarà come questo:

inserisci qui la descrizione dell'immagine

Quindi se aggiungessimo override string ToStringalla nostra classe come:

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

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

Il risultato cambierà e otteniamo l'ordine e il nome del test come:

inserisci qui la descrizione dell'immagine

Nota:

  1. Questo è solo un esempio per illustrare come ottenere nome e ordine nel test, l'ordine è preso numericamente / alfabeticamente quindi se hai più di dieci test ti suggerisco di fare Test 01, Test 02 .... Test 10, Test 11 ecc. Perché se si effettua il Test 1 e ad un certo punto il Test 10 rispetto all'ordine sarà Test 1, Test 10, Test 2 .. ecc.
  2. L'input e Expected può essere qualsiasi tipo, stringa, oggetto o classe personalizzata.
  3. Oltre all'ordine, la cosa buona qui è che vedi il nome del test che è più importante.
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.