2013-11-27 7 views
5

Sto cercando le possibilità di testare un set di plugin di eclipse senza dover utilizzare un singolo bundle per ogni plug-in che viene testato. Attualmente ho una build PDE in esecuzione per un prodotto Eclipse (circa 70 plugin, funzionalità e un prodotto). Tutti i test unitari di tutti i plug-in sono contenuti insieme in un singolo progetto plain-java, con un riferimento al progetto Eclipse a tutti i plugin per poter istanziare le classi ed eseguire i test. Questa configurazione non funziona più poiché ho convertito la build PDE in maven tycho, dal momento che il progetto java non tiene traccia di tutti i progetti della piattaforma target. Non sto eseguendo veri test di plug-in per OSGI, ma alcuni test richiedono che le classi di eclipse core come IProgressMonitor siano contenute nel classpath, poiché utilizzo le interfacce di runtime di eclipse anche nelle proprie firme di metodo.Eclipse Tycho: test dei plug-in senza utilizzare singoli bundle di test

Dopo aver impostato la nuova build di Maven Tycho con successo ho provato un paio di possibilità per ottenere i test in esecuzione di nuovo:

1) Conversione del progetto di test plain-Java in un progetto di test plug
Svantaggi:
- al fine di essere in grado di testare le classi in pacchetti interni, devo esportare ogni singolo pacchetto con x-amico: notazione e necessario ripetere la procedura per ogni nuovo pacchetto testato

2) l'aggiunta di una seconda cartella di origine in ciascun plugin e sposta i test nel plug-in corrispondente
Svantaggi:
- Tycho sembra utilizzare build.properties per includere le cartelle di origine necessarie per il passaggio di compilazione. Poiché sia ​​src/main/java che src/test/java devono essere registrati come cartella di origine, le classi reali e le classi di test vengono confuse nella cartella di destinazione/classi e infine contenute nel file JAR del plugin. Non ho trovato un modo per configurare tycho per usare src/main/java come sourceDirectory e src/test/java come testSourceDirectory.
- Tycho esegue i test di unità solo se il tipo di pacchetto è "eclipse-test-plug"
- Sonar sembra non riconoscere i test eseguiti in questo modo (non ho speso un sacco di tempo a cercare di risolvere questo problema, forse c'è una soluzione facile a questo punto)

3) Aggiungere i necessari bersaglio Eclipse plugin piattaforma come plain-maven dipendenza al progetto di test pianura-java
Svantaggi:
- le informazioni piattaforma di destinazione è duplicato , una volta nella piattaforma di destinazione per il build tycho e una volta nella lista delle dipendenze del progetto di test (eseguita con plain maven-surefire)
- fasci piattaforma target vengono distribuiti due volte nella Artifactory, una volta come piattaforma di destinazione filmati p2, e una volta come dipendenze Maven (plug + POM)

4) Aggiunta di un frammento di prova per ogni plugin (questo sembra essere la possibilità di solito scelta)
Svantaggi:
- Richiede un enorme sforzo (> 70 plugins,> 4500 test di unità), quindi avrei bisogno di aggiungere circa 70 nuovi frammenti e dividere tutti i test.

Al momento, la possibilità 3) sembra la più ragionevole per me ... qualche suggerimento? otherideas?

+0

Solo un'altra idea: potresti anche unire i 70 bundle insieme ... Ma se c'è un buon motivo per separare il codice produttivo in bundle, probabilmente ha anche senso separare i test. Non vedo perché i test debbano essere trattati separatamente (a parte gli sforzi di migrazione). – oberlies

+0

Sarebbe sicuramente sensato dividere il progetto di test in singoli pacchetti, ma ciò richiederebbe settimane di lavoro che non abbiamo (e non ci pagano). Abbiamo deciso di utilizzare l'approccio 3, ma di fronte ad altri problemi, ho aggiornato la domanda di cui sopra. Suggerimenti? – Paolo

+0

Paolo, è fantastico che tu aggiorni il tuo post con i risultati, ma dovresti mettere la tua soluzione in una risposta. La risposta alla tua stessa domanda è esplicitamente consentita su stackoverflow. – oberlies

risposta

1

Infine abbiamo utilizzato l'approccio 3

Purtroppo in aggiunta a svantaggio menzionato sui vasi piattaforma di destinazione, abbiamo anche scoperto che abbiamo bisogno di aggiungere ogni dipendenza di terze parti per due volte. Ad esempio, la dipendenza apache-commons-math doveva essere aggiunta una volta nel plugin produttivo A (jar nella cartella lib, e referenziata in manifest come bundle-classpath) e una volta come dipendenza maven nel progetto di test POM. Non abbiamo trovato altro modo per ottenere la compilazione del progetto di test. Fondamentalmente il progetto di test non riconosce il file jar incluso nel plugin Eclipse A, poiché è una dipendenza da Eclipse e non da un Maven. D'altro canto, se aggiungo la libreria come dipendenza Maven nel plugin A e rimuovo il jar dalla cartella lib, l'IDE di Eclipse non è in grado di compilare il progetto, poiché la libreria è mancante (le dipendenze di Maven non vengono risolte attraverso M2E, se il progetto ha pacchetto di tipo eclipse-plugin)

nostra messa a punto ora assomiglia a questo (semplificato):.

Parent POM

  • plug-in Eclipse A, tipo di pacchetto eclipse-plugin , [apache-commons-math nella cartella lib, aggiunto a Manifest Bundle-ClassPath]

  • Plug-in Eclipse B, tipo di pacchetto eclipse-plugin

  • Test Project, tipo di pacchetto jar, Maven Dipendenza in POM per Plugin A e B e Maven Dipendenza da apache-commons-matematica.

Qualche suggerimento?