Test di Java come Groovy

4

Stiamo cercando di migliorare il nostro processo di test per alcune delle nostre applicazioni e l'idea che è stata avanzata per scrivere test di unità in Groovy e eseguirli automaticamente con Maven.

La prima applicazione per ottenere questo trattamento è scritta in Java, ma mi è stato detto che alcune delle classi testate devono essere rinominate come file ".groovy" * e saranno quindi compilate come classi Groovy, non come classi Java. Questa rinomina può essere fatta usando Maven e Ant, ma sono preoccupato che se compiliamo le nostre classi come classi di Groovy, in realtà non li testiamo come classi Java, che è il modo in cui verranno distribuite.

Durante la demo, è stato anche mostrato che Groovy non compilava lo stesso bytecode di Java. C'era almeno un membro specifico di Groovy che è stato aggiunto, chiamato "metaClass" (ce ne sono stati altri, non ho avuto abbastanza un'occhiata allo schermo). Apparentemente questo è necessario per il framework di testing che vogliono utilizzare, che è denominato Spock .

Ho ragione di essere preoccupato per questo? Importa?

  * Mi è stato detto che questo è per motivi tecnici che hanno a che fare con il modo in cui l'applicazione è costruita. Mi è stato detto che questo non si applica alle classi tutte , ma ad alcune.

    
posta FrustratedWithFormsDesigner 26.02.2013 - 21:01
fonte

2 risposte

6

Le informazioni che ti hanno dato sono sbagliate.

Groovy può interagire con le classi Java senza problemi. Infatti, la maggior parte delle classi del nucleo di Spock sono classi Java (.java) e non Groovy.

I problemi relativi al test delle classi Java con Groovy sono causati da Maven (beh non direttamente da Maven, ma dai plugin responsabili della compilazione e dell'esecuzione dei test).

Per qualche motivo l'interazione tra il plugin Groovy e il plug-in di test di Maven (surefire) fa schifo. (Vedi UPDATE non fa schifo nelle versioni recenti di GMaven).

Mi sono imbattuto in questo problema molto tempo fa. Che probabilmente è causato dal modo in cui è stato impostato il programma di caricamento di classe per l'esecuzione del test. Non posso darti una risposta su come risolvere il problema di compatibilità di Maven Groovy / Surefire, perché in quel momento invece di provare a sistemarlo ho preso per me il percorso più veloce: sono passato da Maven a Gradle.

E riguardo le differenze sulla compilazione ... non fare il .java a .groovy rinomina. Groovy è un meraviglioso linguaggio dinamico ed è facile migrare da Java a Groovy. Ma non è esattamente la stessa lingua, ci sono alcune piccole differenze da tenere in considerazione: link

Quindi se rinomini automaticamente i file per il test, c'è una buona probabilità che alcune cose non si compileranno come i letterali di array, oppure si compileranno con un semantico diverso come == .

Quindi il mio consiglio è: Spock è un meraviglioso framework per i test e Groovy può farti risparmiare un sacco di codice ripetitivo. Puoi migrare tutto in Groovy, ma questa decisione richiede una valutazione più approfondita degli aspetti tecnici del tuo progetto. Se si desidera utilizzare Groovy per i test e Java per le classi principali, cercare una soluzione nella comunità Maven o provare a passare la build su Gradle.

Nota aggiuntiva: il compilatore Groovy è un superset del compilatore Java. Quando un file .java viene dato al compilatore Groovy, usa il compilatore Java. Significa che puoi mescolare .java e .groovy nella stessa directory e usare il compilatore Groovy per compilare tutto. Forse questa configurazione ti aiuta con il plug-in di test di Maven.

UPDATE: Recentemente ho dovuto lavorare con un progetto usando Spock e Maven 3. Far coesistere entrambi è più facile di prima:)

Innanzitutto, configura il tuo plugin GMaven, puoi vedere un esempio qui: link

Quindi devi configurare Surefire in modo che visualizzi le tue classi di test:

        <plugin>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>2.14</version>
            <configuration>
                <includes>
                    <include>%regex[.*Spec.*]</include>
                </includes>
            </configuration>
        </plugin>

Il trucco è nell'espressione regex poiché, secondo i documenti Surefire, si applica alle classi (se non si utilizza regex si applica ai file sorgente).

    
risposta data 08.03.2013 - 23:45
fonte
3

Per quanto ne so, è possibile scrivere i test di unità in Groovy (file .groovy) mentre il codice dell'applicazione reale rimane Java puro, purché i test non presuppongano l'uso di funzionalità avanzate di Groovy in cima a Classi di applicazioni Java (come mixin e categorie - che decorano la classe Java con una metaClass). Da Groovy puoi testare getter e setter di POJO usando chiamate java standard, senza avere il codice di test del boilderplate che spesso hai in Java. Groovy consente anche di implementare facilmente oggetti fittizi di classi specifiche per il test (utile quando si verifica la conformità API per esempio).

Groovy ha sempre accesso alle classi Java sul classpath. Hai solo bisogno delle librerie giuste nel classpath usato per testare e abilitare la compilazione Groovy sulle tue origini di test. Proprio come i file jar JUnit vengono utilizzati solo per i test unitari, così può essere inclusa la distribuzione binaria groovy-all durante il test, ma non essere inclusa nel percorso della classe in fase di compilazione o di esecuzione della stessa sorgente dell'applicazione.

Non ho alcuna storia con lo stesso framework Spock, quindi non posso commentare la validità delle informazioni a riguardo.

Cosa si riduce a: se si compilano le classi dell'applicazione utilizzando un compilatore java (e non un compilatore groovy), si avrà lo stesso codice byte, indipendentemente dal framework di test che si utilizza.

    
risposta data 26.02.2013 - 23:16
fonte

Leggi altre domande sui tag