Escludere singoli metodi JUnit prova senza modificare la classe di test?

Question

Attualmente sto ri-utilizzando JUnit 4 test da un altro progetto contro il mio codice. li ottengo direttamente dal repository di L'altro progetto come parte del mio Ant automatizzato. Questo è grande, in quanto garantisce tengo il mio codice verde contro la più recente versione di test.

Tuttavia, v'è un sottoinsieme di test che non mi aspetto mai di trasmettere il mio codice. Ma se comincio aggiunta di annotazioni @Ignore a quei test, dovrò mantenere la mia copia separata della realizzazione di test, che I davvero non vogliono fare.

C'è un modo di escludere le prove individuali senza modificare la fonte di prova? Ecco quello che ho guardato finora:

• Per quanto posso vedere, il compito Ant JUnit consente solo di escludere intere classi di test, non i singoli metodi di prova -. In modo che non va bene per me, ho bisogno di metodo granularità

• Ho considerato mettendo insieme un TestSuite che utilizza la riflessione per trovare in modo dinamico e aggiungere tutti i test originali, quindi aggiungere il codice per rimuovere in modo esplicito i test che non voglio correre. Ma ho mollato l'idea quando ho notato che il TestSuite API non fornisce un metodo per la rimozione di test.

• posso creare le mie classi di test che estendono le classi di test originali, sovrascrivere i test specifici che non voglio correre, e li annotare con @Ignore. Ho poi corro JUnit sul mio sottoclassi. Il rovescio della medaglia è che se nuove classi di test vengono aggiunti al progetto originale, non voglio raccoglierli automaticamente. Dovrò controllare per le nuove classi di test che vengono aggiunti al progetto originario. Questo è il mio migliore opzione fino ad ora, ma non si sente l'ideale.

• L'unica altra opzione mi viene in mente è quello di eseguire i test male comunque e ignorare i fallimenti. Tuttavia, questi test prendere un po 'a correre (e fallire!) Quindi preferisco non correre affatto. Inoltre, non riesco a vedere un modo di raccontare il compito Ant di ignorare i guasti sui metodi di prova specifici. (Ancora una volta - non vedo come si può fare per le singole classi di test, ma non i metodi)

Answer 1

Se non si può toccare il test originale a tutto quello che si sta per avere alcune limitazioni gravi. Il vostro imperativo suona come la migliore scommessa, ma con un paio di modifiche:

Costruire le prove di Ant specificamente escluse le classi eccellenti, in modo che le classi aggiuntive che non si conoscono eseguire Get.

È possibile utilizzare l'annotazione @Rule (nuovo a JUnit 4.7) di sapere che cosa prova è in esecuzione e abortire (restituendo un'implementazione Dichiarazione vuoto) e non viene sostituito metodi specifici, offrendo una maggiore flessibilità nel sapere o meno di evitare il test. L'unico problema di questo metodo è che non si può fermare i metodi @Before esecuzione utilizzando questo metodo, che può essere lenta. Se questo è un problema (e davvero non si può toccare i test) e poi @Ignore nel metodo sovrascritto è l'unica cosa che posso pensare.

Se, tuttavia, si può toccare questi test, alcune opzioni aggiuntive si aprono:

Si poteva correre con un corridore personalizzato specificando il tag @RunWith sulla classe. Questo corridore sarebbe solo passare l'esecuzione per il corridore standard (JUnit4.class) in quel progetto, ma nel progetto (tramite una proprietà di sistema o qualche altro meccanismo) sarebbe ispezionare il nome del test e non eseguire un test. Questo ha il vantaggio di essere meno invadente, ma il più difficile da implementare (corridori sono bestie pelose, uno degli obiettivi dichiarati del @Rule era quello di eliminare la maggior parte delle necessità di farli).

Un altro è di fare una dichiarazione assumeThat sul test che avrebbe controllare alcune impostazioni di configurazione che sarebbe vero se questo test deve essere eseguito. Questo sarebbe in realtà coinvolgere iniettando direttamente nel test, che è molto probabilmente una garanzia di insuccesso in qualche cosa etichettata in remoto un "progetto separato".

Answer 2

Non aiuta te ora, ma TestNG supporta questo tipo di capacità.

Answer 3

OK, questa è una soluzione piuttosto pesante, ma non gettare le cose a me se suona ridicolo.

Il nucleo Junit4 è la classe org.junit.runner.Runner, e le sue varie sottoclassi, soprattutto org.junit.runners.Suite. Questi corridori determinare quali i test sono per una determinata classe di test, utilizzando le cose come @Test e @Ignore.

E 'abbastanza facile per creare implementazioni personalizzate di un corridore, e normalmente li avrebbe collegare utilizzando l'annotazione @RunWith sulle classi di test, ma ovviamente questo non è un'opzione per voi.

Tuttavia, in teoria, si potrebbe scrivere il proprio compito Ant, forse in base all'operazione Ant Junit standard, che toglie il test runner personalizzato e lo usa direttamente, passando ogni classe di test ad esso a sua volta. L'implementazione corridore potrebbe utilizzare un file di configurazione esterna che specifica i metodi di prova per ignorare.

Sarebbe un bel po 'di lavoro, e che avrebbe dovuto trascorrere del tempo a scavare in giro per il preistorico codebase Ant Junit per scoprire come funziona. L'investimento in tempo può essere valsa la pena, però.

E 'solo un peccato che il compito Junit Ant non fornisce un meccanismo per specificare il test runner, che sarebbe l'ideale.

Answer 4

Una possibilità mi viene in mente per ottenere ciò che si vuole con i vincoli indicati è quello di utilizzare la modifica bytecode. Si potrebbe tenere un elenco di classi e metodi per ignorare in un file separato, e patchare il bytecode delle classi di test, come si carica loro di rimuovere questo metodi del tutto.

Se non mi sbaglio, JUnit utilizza la riflessione per trovare i metodi di prova da eseguire. Un'operazione metodo di ridenominazione potrebbe quindi consentire di rimuovere questi metodi prima di JUnit li trova. O il metodo può essere modificato per restituire immediatamente, senza eseguire alcuna operazione.

Una biblioteca come BCEL può essere utilizzato per modificare le classi quando vengono caricati.

Answer 5

Se si desidera eseguire solo un sottoinsieme dei test Sembra che la classe ha più di un responsabilità e dovrebbe essere refactoring verso il basso. In alternativa la classe di test potrebbe essere spezzato in modo che il progetto originale aveva tutti i test, ma su una o più classi (sto cercando di indovinare alcuni dei test sono davvero test di integrazione e toccare il database o di rete) e si poteva escludere la classe ( es) non volevi.

Se non si può fare nulla di tutto ciò, l'opzione di principale è probabilmente la cosa migliore. Prendete il processo di ogni volta che è necessario ignorare alcuni metodi che si estendono quella classe e aggiungerlo alla tua lista Ant escludere. In questo modo è possibile escludere ciò che non si può passare e sarà ancora tirare in tutti i nuovi test (metodi non avete override e nuove classi di test) senza modificare il build.

Answer 6

Se le prove indesiderati sono in specifiche classi / pacchetti, è possibile utilizzare un set di file esclude in Ant per escluderli durante l'importazione.

Answer 7

Due opzioni

1. Lavora con il proprietario dei test presi in prestito per estrarre i vostri in una classe separata che si sia in grado di condividere.
2. Crea la tua classe di test che proxy classe di test che si desidera utilizzare. Per ogni metodo che si desidera includere avere un metodo nella classe. Avrete bisogno di costruire un'istanza della classe di test che si sta chiamando e fare prima e dopo i metodi troppo se sono in originale.
3. Crea un corridore Junit personalizzata basata su blockjunitrunner e utilizzarlo per filtrare o nei test che si desidera.