Un metodo per test unitario?

Question

Un metodo per test unitario?

#1 da (6 voti)
#2 da (3 voti)

1

Supponiamo che abbia un metodo Service Layer come questo:

public void TestMethod()
{
   DomainObject domainObject = new DomainObject();
   domainObject.TestMethod();
}

TestMethod ha questo aspetto nel livello di dominio:

public void TestMethod()
{
   TestMethod1();
   TestMethod2();
   TestMethod3();
}

È una cattiva pratica sottoporre questa unità a questo metodo? Il motivo per cui lo chiedo è perché il Domain Object.TestMethod chiama altri tre metodi. La mia lettura mi dice che dovresti testare solo un metodo per test unitario.

unit-testing c#

posta w0051977 16.05.2017 - 18:26

fonte

2 risposte

Leggi altre domande sui tag unit-testing c#

Debug di errori multipli C'è qualche ragione per non usare const anche se è possibile?

score 6 · Answer 1

Devi assolutamente testare questo metodo del livello di servizio. Altrimenti, come fai a sapere se funziona?

Anche se si hanno test unitari individuali che garantiscono che ciascuno di TestMethod1 (), TestMethod2 () e TestMethod3 () funzionino come previsto, ciò non garantisce che TestMethod () funzioni come previsto. Per esempio. potrebbe chiamare i metodi nell'ordine sbagliato, o questo insieme di metodi potrebbe essere il metodo sbagliato da chiamare per raggiungere il suo scopo.

A volte si afferma che un test unitario dovrebbe testare un solo metodo, ma questo si riferisce solo a un singolo metodo al livello più alto nel test unitario. Certamente il metodo testato potrebbe chiamare a sua volta altri metodi.

score 3 · Answer 2

Che cosa stai testando? Stai testando TestMethod . Se l'implementazione di TestMethod cambia, devi comunque testarla. Il test dovrebbe essere il più indipendente possibile dall'implementazione, quindi è importante testare questo metodo.

My reading tells me that you should only test one method per unit test.

Suggerirei di voler testare un metodo di invocazione / metodo del componente in prova per metodo, perché altrimenti il test dell'unità finisce per testare molto e se la prima chiamata fallisce, hai vinto avere la possibilità di invocare anche i metodi successivi. Tuttavia, il modo in cui tale metodo viene implementato dovrebbe risultare opaco al test. Se cambi questa implementazione in futuro, il tuo test dovrebbe rimanere lo stesso, e quindi conferma che il tuo refactoring non ha modificato il comportamento di quel metodo in modo imprevisto.