Il modo migliore per costruire i nostri soggetti di prova nei test unitari?

1

Alcune delle nostre classi di business logic richiedono alcune dipendenze (nel nostro caso 7-10). Come tale quando arriviamo al test unitario, la creazione diventa piuttosto complessa.

Nella maggior parte dei test queste dipendenze spesso non sono richieste (solo alcune dipendenze sono richieste per particolari metodi).

Di conseguenza, i test unitari richiedono spesso un numero significativo di righe di codice per simulare queste dipendenze inutili (che non possono essere nulle a causa dei controlli null).

Ad esempio:

[Test]
public void TestMethodA()
{    
  var dependency5 = new Mock<IDependency1>();
  dependency5.Setup(x => x. // some setup

  var sut = new Sut(new Mock<IDependency1>().Object,
    new Mock<IDependency2>().Object,
    new Mock<IDependency3>().Object,
    new Mock<IDependency4>().Object,
    dependency5);

  Assert.SomeAssert(sut.MethodA());    
}

In questo esempio quasi la metà del test è occupata dalla creazione di dipendenze che non vengono utilizzate. Ho studiato un approccio in cui ho un metodo di supporto.

[Test]
public void TestMethodA()
{    
  var dependency5 = new Mock<IDependency1>();
  dependency5.Setup(x => x. // some setup    
  var sut = CreateSut(null, null, null, null, dependency5);

  Assert.SomeAssert(sut.MethodA());    
}

private Sut CreateSut(IDependency1 d1, IDependency2 d2...)
{
  return new Sut(d1 ?? new Mock<IDependency1>().Object,
    d2 ?? new Mock<IDependency2>().Object,
}

Ma spesso queste cose si complicano molto rapidamente.

Qual è il modo migliore per creare queste classi BLL nelle classi di test per ridurre la complessità e semplificare i test?

    
posta Liath 19.08.2014 - 14:09
fonte

2 risposte

4

Li costruisci in qualunque modo tu abbia bisogno di loro costruiti, e poi applichi buone pratiche standard al codice risultante: DRY, refactoring, single-responsability, ecc.

È diffusa l'impressione che sia sbagliato spendere troppi sforzi per testare il codice a causa di una vaga convinzione che non sia un codice "reale". Questo è molto sbagliato.

Il codice di prova appartiene alla tua base di codice e contribuisce alla sua eccellenza tanto quanto ogni altro tipo di deliverable. Il fatto che non sia (normalmente) spedito al cliente è irrilevante. Se vale la pena scrivere un codice di test perché consente di risparmiare tempo in generale, vale la pena scrivere un codice di test ben progettato perché consente di risparmiare ancora più tempo.

Pertanto, non c'è assolutamente nulla di sbagliato nell'avere classi di helper solo usate nei test unitari, o inventare oggetti finti più complicati di quanto lo schema di derisione delle tue preferenze possa auto-generare, se è ciò che è necessario per mettere le cose sotto esame In effetti, questo è il modo migliore per definizione.

    
risposta data 19.08.2014 - 15:11
fonte
3

alcune cose:

1) 10 dipendenze è troppo. probabilmente stai perdendo uno strato di astrazione. vedere: link

link

2) ci sono framework di automock come:

link

3) C'è anche link per semplificarti la vita

    
risposta data 19.08.2014 - 14:19
fonte

Leggi altre domande sui tag