Scrivi precondizioni comuni per un numero elevato di casi di test unitari?

"what exactly is the purpose of setUp() method in Junit that runs before each test case ?"

Isolamento.

Se una risorsa condivisa, ad es. un falso deposito persistente, viene utilizzato da ogni caso di test, è necessario assicurarsi che sia nello stesso stato all'inizio di ogni test.

Altrimenti, se non inizializzi un negozio in quel modo e i tuoi test (con la convenzione di denominazione: MethodUnderTest_Condition_ExpectedBehaviour) vengono eseguiti in un ordine, ad esempio:

1: AddObject_GivenObject_AddsObjectToStore
2: GetObjectById_IdThatExistsInStore_ReturnsObject

quindi il test 2 dipende dal test 1 che aggiunge l'oggetto al negozio e non è più un test unitario corretto. Se vengono eseguiti in un ordine diverso, il codice di lavoro di GetObjectById () non supererà il test dell'unità, fornendo un falso negativo.

I buoni test unitari non hanno un ordine necessario per essere eseguiti.

"this dependency may cause large number of test cases to fail if something changes ."

Questa è una buona cosa, quelle unità testano ciascuna prova in modo diverso e falliscono in modo appropriato. Se si tratta di una piccola modifica che ha causato il fallimento, sarà una piccola correzione che farà passare nuovamente i test.

Penso che tu abbia bisogno di trovare un equilibrio. Se hai delle precondizioni comuni, allora sì, potresti avere test fragili, ma anche un minor numero di posti da cambiare se hai davvero bisogno di quelle precondizioni per quel set di test, e queste condizioni preliminari devono cambiare. (Valutare attentamente).

Spesso trovo che se utilizzo un framework di simulazione, potrei creare un set di base di oggetti mock e potenzialmente inserirli dove ne ho bisogno nel metodo setUp (o JUnit 4 @Before) e definire cosa fanno in i singoli test.

O se usi JUnit per l'integrazione o test più ampi, @Before / @BeforeClass può essere un momento per impostare i contenitori di jetty, configurare i database di simulazione / file di dati, prendere altre risorse necessarie e assicurarti che vengano rilasciate in @ Dopo / @AfterClass anche se i test falliscono.

Modifica: ho glazed su questo ... In JUnit 4 l' annotazione @BeforeClass indica un metodo statico che viene eseguito solo una volta prima di tutti i test in esecuzione in una classe. Non posso commentare troppo per JUnit 3, ma una rapida ricerca ha rivelato questo post del blog che è sembrato interessante.

Non posso commentare Junit, ma utilizzo MbUnit e utilizzo i metodi di impostazione e rimozione per l'impostazione e la riduzione dell'input delle dipendenze, in particolare UnityContainer di MS.

Penso che le precondizioni comuni siano OK con moderazione, ma troppe renderanno i test fragili.

L'utilizzo di vari sapori di SetUp () / TearDown () abilita l'isolamento del test. Ma è anche utile eliminare la duplicazione del codice.

Ricorda: tratta il codice di prova nello stesso modo in cui tratti il codice di produzione. Questa pratica aiuta a ridurre la duplicazione nel codice di prova, quindi usalo dove è appropriato.

Tuttavia, bisogna fare attenzione a includere solo le cose che sono veramente comuni per tutti i test nel gruppo (test fixture?) che useranno l'utility SetUp () comune. Se usato solo da alcuni di essi - aumenterai la complessità del codice di test - che è peggio della duplicazione nella mia mente ...