Mi interessa la ridondanza Junit quando utilizzo setUp () con l'annotazione @Before?

Question

Mi interessa la ridondanza Junit quando utilizzo setUp () con l'annotazione @Before?

#1 da (4 voti)
#2 da (1 voti)
#3 da (0 voti)

3

Anche se gli sviluppatori sono passati da junit 3.x a 4.x, vedo ancora il dopo il 99% delle volte:

@Before
public void setUp(){/*some setup code*/}

@After
public void tearDown(){/*some clean up code*/}

Giusto per chiarire il mio punto ... in Junit 4.x, quando i corridori sono impostati correttamente, il framework prenderà le annotazioni @Before e @After indipendentemente dal nome del metodo. Quindi, perché gli sviluppatori continuano a utilizzare gli stessi nomi convenzionali 3.x di junit? C'è qualche danno nel mantenere i vecchi nomi mentre si usano anche le annotazioni (a parte il fatto che mi sento come se gli sviluppatori non sapessero come funziona davvero e, nel caso, usare lo stesso nome E anche annotazioni) ?

C'è qualche danno nel cambiare i nomi in qualcosa forse più significativo, come eachTestMethod() (che sembra ottimo con @Before poiché legge "prima di ogni metodo di prova") o initializeEachTestMethod() ?

Che cosa fai e perché?

So che questa è una cosa minuscola (e probabilmente potrebbe anche non essere importante per alcuni), ma è sempre nella mia mente quando scrivo un test e lo vedo. Voglio seguire questo schema o no, ma voglio sapere perché lo sto facendo e non solo perché anche il 99% dei miei colleghi sviluppatori lo fa.

conventions junit

posta c_maker 29.02.2012 - 02:56

fonte

3 risposte

1

L'ho sempre chiamato setUp perché c'è molto poco da guadagnare in termini di rendere i miei test più istruttivi. Se vedessi qualcuno chiamare setUp qualcos'altro, mi aspetterei che il nuovo nome sia particolarmente importante in qualche modo a causa della divergenza dagli standard.

risposta data 29.02.2012 - 05:20

fonte

0

Uso setUp () quando non riesco a pensare ad un nome migliore. Parte del problema è che il metodo setUp ha una varietà di cose in modo che un altro nome non si presenti.

C'è un problema con l'utilizzo di setUp per tutti i metodi. Devi ricordarti di chiamare il setUp della superclasse se esiste. A differenza di JUnit 3.8, dove puoi farlo sempre.

Quando scrivo un test astratto, mi sforzo di usare un nome che sia not setUp () per evitare di mettere questo onere sugli implementatori delle sottoclassi. Certo, è abbastanza ovvio che ci sia un problema dovuto a NullPointer. Ma scrivere una superclasse di test è come scrivere codice riutilizzabile. Vuoi rendere le cose facili per i chiamanti!

risposta data 15.04.2012 - 17:46

fonte

Leggi altre domande sui tag conventions junit

Chiarimento sul modello di strategia guarda cosa fa ARC?

score 4 · Accepted Answer

Le persone usano gli stessi nomi di metodo perché è una convenzione e la gente lo sa già. Non c'è niente di sbagliato nell'usare un nome diverso, rende le cose un po 'più difficili. Non penso che i tuoi esempi siano più chiari rispetto all'uso di setUp() .

Alla fine della giornata, le persone lo fanno perché il 99% dei loro colleghi sviluppatori lo fanno. Se hai una classe di test che sta facendo qualcosa di molto particolare nel suo metodo di installazione, pensi che un nome più specifico sia d'aiuto, quindi puoi farlo. Tuttavia, allo stesso tempo, prenderei in considerazione di dare una seconda occhiata al test se il metodo di installazione sta facendo abbastanza lavoro che setUp() non è abbastanza descrittivo. Il test ha troppe dipendenze? Puoi scomporlo in unità più piccole?