Quando collaudi unità usando aspettative, definisci un insieme di chiamate metodo e risultati corrispondenti per quelle chiamate. Questi definiscono il percorso attraverso il metodo che vuoi testare.
Ho letto che i test unitari non devono duplicare il codice. Ma quando definite queste aspettative, non è la duplicazione del codice, o almeno il processo? Come fai a sapere quando stai duplicando la funzionalità in prova?
Le aspettative dovrebbero essere diverse, ma se stai testando un insieme di aspettative comuni a più test unitari dovresti usare variabili e oggetti condivisi.
Questo è anche il motivo per cui hai i metodi setUp e tearDown per i framework xUnit.
Alcuni framework fanno un ulteriore passo avanti permettendoti di impostare con nesting come Jasmine ( BDD / TDD per Javascript).
Dipende da quanto banali sono i metodi che stai testando.
Esempio A - codice banale, test (s) banali
public class SomeClass
{
public string SomeStringProperty { get; set; }
public SomeClass(string someString)
{
SomeStringProperty = someString;
}
}
[TestMethod]
public void SomeClassConstructorSetsSomeStringProperty()
{
string testString = "abc";
SomeClass some = new SomeClass(testString);
Assert.AreEqual(testString, some.SomeStringProperty);
}
Salva metodi, getter di proprietà, setter e semplici costruttori rientrano tutti in questa categoria. I metodi e le asserzioni di installazione saranno semplici e assomigliano al codice in esame fino al punto in cui si penserebbe che siano duplicati. Molti articoli su come eseguire il test delle unità hanno esempi banali come questo, e poi la gente pensa che i test unitari non siano così preziosi. Non li incolpo di pensare che se questi sono gli unici esempi che hanno visto.
Esempio B: codice più complesso, più test richiesti.
public class PaymentCalculator
{
public int DayOfMonth { get; set; }
public int IsRecipientLikable { get; set; }
public decimal PaymentAmount()
{
decimal payment = 0;
if (DayOfMonth < 15) payment += 100;
if (IsRecipientLikable) payment *= 6;
return payment;
}
}
[TestMethod]
public void PaymentOn4thForLikeablePersonIs600Dollars()
{
var calc = new PaymentCalculator { DayOfMonth = 4, IsRecipientLikable = true };
Assert.AreEqual(600, calc.PaymentAmount());
}
Ovviamente, questo test non coprirà tutte le condizioni del tuo "calcolatore", quindi dovrai scriverne molti altri.
In breve, più la logica aziendale è complessa, più i test possono essere significativi e meno duplicati.
Leggi altre domande sui tag unit-testing code-smell