NUnit specifica TestCaseAttribute sull'implementazione o crea un metodo di prova

Question

NUnit specifica TestCaseAttribute sull'implementazione o crea un metodo di prova

#1 da (3 voti)

1

Basato su questa domanda sull'uso corretto di nUnit's TestCaseAttribute , mi chiedevo se specificare il caso di test direttamente sull'implementazione o creare metodi di test (come quando si usa esplicitamente Assert.AreEqual ecc.).

Nel seguito ho specificato degli esempi per entrambi gli approcci e ho anche elencato potenziali argomenti a favore e contro entrambi i casi a cui potevo pensare.

Specifica del test sull'implementazione

public class Math
{
    [TestCase(1, 2, ExpectedResult = 3)]
    public int Add(int a, int b)
    {
        return a + b;
    }
}

Pro:

Meno codice per scrivere
TestCase funziona come documentazione

Contro:

dovendo fare riferimento a nunit.framework.dll nel progetto di implementazione

Creazione di un metodo di prova

public class Math
{
    public int Add(int a, int b)
    {
        return a + b;
    }
}

public class MathTest
{
    [TestCase(1, 2, ExpectedResult = 3)]
    public int AddTest(int a, int b)
    {
        return new Math().Test(a, b);
    }
}

Pro:

Non è necessario fare riferimento a nunit.framework.dll nel progetto di implementazione, solo nel progetto di test
I test sono chiaramente separati dal codice che testano

Contro:

Duplicazione del codice: il metodo di prova ha esattamente la stessa firma dell'attuale implementazione ecc.
altro codice da scrivere
test non funziona più come una sorta di documentazione

Esistono altri argomenti a favore o contro uno degli approcci menzionati?

Quale approccio dovrei seguire? (come in quale approccio viene generalmente utilizzato, che è considerato "Better Practice"?)

tdd unit-testing c# programming-practices nunit

posta Thomas Flinkow 31.10.2018 - 11:06

fonte

1 risposta

Leggi altre domande sui tag tdd unit-testing c# programming-practices nunit

Quando utilizzare il modello di Messenger (Mediatore) nel design MVVM Versione del fornitore di hardware SDK con git

score 3 · Accepted Answer

Allo stato attuale, non stai ottenendo alcun risultato con nessuno dei due metodi rispetto a un semplice metodo di prova:

[TestFixture]
public class MathTest
{
    [Test]
    public void AddTest()
    {
        Assert.AreEqual(3, new Math().Add(1,2));
    }
}

Dove [TestCase] ha un suo valore utilizza l'unico metodo per test multipli:

[TestFixture]
public class MathTest
{
    [TestCase(1, 2, ExpectedResult = 3)]
    [TestCase(-1, 2, ExpectedResult = 1)]
    [TestCase(-1, -2, ExpectedResult = -3)]
    public int AddTest(int a, int b)
    {
        return new Math().Add(a, b);
    }
}

Ma una cosa è certa: l'aggiunta di dati di test direttamente al codice di produzione è generalmente considerata una cattiva idea. Ingombra il codice e, tranne che in casi banali come il tuo esempio, spesso è necessario un codice di supporto aggiuntivo per i test, che dovrebbe anche essere incluso nel codice di produzione, complicando ulteriormente le cose mentre sfiorano il principio di responsabilità singola.

Quindi attenersi a due assembly separati: codice di produzione e casi di test, indipendentemente dal fatto che si utilizzi [TestCase] o meno.