Provando il Java EE 6 Galleria

È ora di andare avanti con Vineet Esempio di Java EE 6 Galleria. After qualche introduzione , una semplice guida introduttiva  su GlassFish e il deployment WebLogic 12c è finalmente il momento di tuffarsi in testing. Ho saltato questa parte nei post precedenti a causa di due motivi. Il primo, ovviamente, era che volevo scrivere un post a parte su di esso. La seconda era che non c'era lavoro da fare per ottenere questo e in esecuzione su GlassFish ultima 3.1.2. Vineet e la squadra ha fatto un ottimo lavoro rilasciando Arquillian GlassFish Remote Container CR3 una schiena pochi giorni, che ora copre anche GlassFish 3.1.2. È ora di iniziare a testare l'esempio Galleria. Quello che stai andando a testare La Galleria è stata costruita per raggiungere una copertura completa di test attraverso l'uso di entrambi i test unitari e di integrazione, scritto in JUnit 4. I test di unità e di integrazione per gli EJB e il modello di dominio contare sul contenitore 3,1 API EJB. I test di integrazione per il livello di presentazione si basa sul progetto Arquillian e la sua estensione Drone (per l'esecuzione di test Selenium). Assicurati di aggiornare alle ultime fonti del Progetto Galleria , perché Vineet aggiornato il contenitore Arquillian GlassFish alla CR3 e la roba Selenio per sostenere ultima versione del browser FireFox. unit test il livello di dominioI test per la caduta del dominio livello in cinque categorie separate. I primi tre (test di verifica Bean, comuni test di verifica, test di registrazione per il costruttore, i metodi Equals e hashCode) coprire le esigenze di base per quasi tutte le applicazioni JPA based. Se fate una passeggiata per le galleria-ejb \ src \ fonti di prova si possono vedere le ricopriva nel pacchetto info.galleria.domain. Ogni oggetto di dominio è coperto da una classe suite che include tutti e tre i tipi di unit test. Consente di iniziare con le prove di verifica guardando le Bean. Il comportamento associato con i getter e setter nelle proprietà di JavaBeans sono abbastanza facili da verificare. Tutto ciò che si deve fare, è quello di invocare il setter, poi il getter, e verificare se l'istanza restituita dal getter è uguale all'istanza passata al setter. Il progetto utilizza la BeanVerifier classe (sotto la root src / test / java della galleria-ejb modulo) per questo. Il test AlbumBeanVerifier è semplicemente un test con parametri che interpella ogni singola proprietà. L'unica eccezione in questo caso è la proprietà coverPhoto che ha un comportamento speciale al di là del modello JavaBean semplici. Avanti nella lista sono i test per il costruttore, i metodi Equals e hashCode.Costruttori per le entità di dominio sono testati da semplice fatto di creare nuove istanze delle classi, pur affermando la validità delle proprietà che sarebbero fissati dal costruttore. I metodi Equals e hashCode vengono verificati tramite l'utilizzo della classe EqualsVerifier dal progetto EqualsVerifier .

L'ultima categoria delle prove più fondamentali sono i  comuni di registrazione  (PDF) test di verifica. Si vuole semplicemente verificare se le modifiche ai rapporti tra le entità, in realtà comportare modifiche sia per il genitore e le proprietà figlio. Vedi la pagina completa wiki per maggiori dettagli circa l'attuazione.Tutti questi sono eseguiti durante la fase di unit test e sono coperti da ** / * classi Suite.java. 
Oltre ai test di base si trova anche una tantum prove scritte per i casi specifici in cui i modelli di base di test risultino insufficienti o inidonei . In tali casi, le una tantum test verificano tali comportamenti attraverso scritti a mano asserzioni. Li trovate in ** / * classi Tests.java nello stesso pacchetto. 
I test di dominio strato di finitura con i test del repository le JPA. Ciascuna delle classi RepositoryTest.java * I CRUD provare il comportamento degli oggetti di dominio gestiti. Il AbstractRepositoryTest comune gestisce i dati di test e ripristina il database dopo ogni test-run. La creazione del database stesso è gestito dal dbdeploy-maven-plugin. Guardando il pom.xml si può vedere, che è associato a due Maven fasi del ciclo di vita (processo-test-risorse e pre-integrazione-test) che si assicura che viene chiamato due volte. La prima volta prima che l'unità di test e secondo prima del test di integrazione (cfr. sotto). 
Tutte queste unità-test vengono eseguiti con infallibile. Se si esegue un test mvn sulla galleria-ejb progetto è possibile vedere un totale di 138 test di passaggio. Questi sono i quattro ** / * test Suite, il quattro ** / * RepositoryTests e due test aggiuntivi. Se una rapida occhiata al l'output della console si vede, che questo sta succedendo tutto in un ambiente Java SE. Nessun test container sono stati fatti fino ad ora. Integration Test del livello di Domain Quindi questo in realtà riguardava solo le nozioni di base che tutti dovrebbero fare e probabilmente lo sa. Fare i test di integrazione è un'altra storia. Questo viene fatto dai ** / * test IntegrationSuite. Il nome volutamente non utilizza di default le convenzioni di denominazione, al fine di impedire loro di esecuzione durante Maven di unit test di fase. Per agganciare nelle fasi di integrazione-test di Maven l'esempio Galleria si avvale del  Plugin Maven Failsafe . Potete trovare la suite di test di integrazione nel pacchetto info.galleria.service.ejb. Il AbstractIntegrationTest prende cura di gestire i dati di prova (paragonabile ciò che il AbstractRepositoryTest) ha fatto per le unit-test. La Suite contiene un ServiceIntegrationTest * per ogni oggetto di dominio. Si può passeggiare attraverso le prove singole in ogni IntegrationTest * e avere un'idea di ciò che sta accadendo qui. Il ServicesIntegrationSuite si prende cura di avviare e arrestare il EJBContainer utilizzando il AbstractIntegrationTest.startup ();. Questo metodo è relativamente semplice e spettacolare:

1.logger.info ( "Avvio del contenitore incorporato." );

2.Mappa <String, Object props = nuova HashMap <String, Object ();

3.props.put ( "org.glassfish.ejb.embedded.glassfish.installation.root" ,

4."/ GlassFish-integrationtest-install / GlassFish." );

5.container = EJBContainer.createEJBContainer (oggetti di scena);

6.context = container.getContext ();

7.datasource = (DataSource) context.lookup ( "jdbc / galleriaDS" );

Il punto più importante qui è che il embeddable EJBContainer viene configurato tramite un dominio esistente GlassFish che si trova direttamente nella galleria-ejb \ glassfish-integrationtest-cartella di installazione. Se si guarda al glassfish \ domains \ domain1 \ config \ domain.xml si può notare, che tutte le configurazioni è già fatto per voi. Ma da dove viene la distribuzione viene? Questo è facile rispondere.Di default il embeddable EJBContainer cerca il vostro classpath per ejb-jar jarfiles o cartelle e li distribuisce. Se volete vedere un po 'più dettagliato di uscita dal EJBContainer è necessario fornire un file customlogging.properties in src / test / resources e aggiungere alcune linee semplici ad esso: 

1.gestori = java.util.logging.ConsoleHandler

2.java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter

3.java.util.logging.ConsoleHandler.level = FINEST

4.# aggiungere i pacchetti qualche altro se ne avete bisogno

5.info.galleria.service.ejb.level = FINI

aggiungere il seguente al-maven-plugin failsafe sezione di configurazione del vostro pom.xml: 

1.< systemPropertyVariables >

2.<java.util.logging.config.file>${basedir}/src/test/resources/customlogging.properties</java.util.logging.config.file>

3.</ systemPropertyVariables >

I test di integrazione dovrebbe terminare con successo e maven dovrebbe stampare qualcosa di paragonabile a quanto segue:

1.Test eseguito: 49, Errori: 0, Errori: 0, ignorati: 0, Tempo trascorso: 61,726 sec

Si noti, che i test di integrazione richiedere molto più tempo rispetto al normale unit-test. Questa non è una sorpresa a tutti e si dovrebbe assicurarsi di loro solo quando è necessario eseguire in modo che non vengono rallentati con il vostro sviluppo. Integration Test del livello di presentazione è coperto Lo strato di dominio con i test. Ciò che manca è il livello di presentazione. Potete trovare le prove strato di presentazione in galleria-jsf progetto. Inizia con l'esame della pom.xml. Potete trovare un paio di nuove dipendenze qui. Vale a dire Arquillian, Selenio e Drone. First alcune configurazioni di nuovo. Scorrere fino alla sezione del profilo è possibile vedere un profilo di integrazione-test che fa uso di maven-glassfish-plugin e controlla un contenitore che è configurato con un paio di proprietà. Aggiungere la definizione alla sezione proprietà sulla parte superiore del pom:

1.< galleria.glassfish.testDomain.user > admin </galleria.glassfish.testDomain.user >

2.<galleria.glassfish.testDomain.passwordFile>D:/glassfish-3.1.2-b22/glassfish3/glassfish/domains/test-domain/config/local-password</galleria.glassfish.testDomain.passwordFile>

3.<galleria.glassfish.testDomain.glassfishDirectory>D:/glassfish-3.1.2-b22/glassfish3/glassfish/</galleria.glassfish.testDomain.glassfishDirectory>

4.< galleria.glassfish.testDomain.domainName > test-domain </galleria.glassfish.testDomain.domainName >

5.< galleria.glassfish.testDomain.adminPort > 10.048 </galleria.glassfish.testDomain.adminPort >

6.< galleria.glassfish.testDomain.httpPort > 10.080 </galleria.glassfish.testDomain.httpPort >

7.< galleria.glassfish.testDomain.httpsPort > 10.081 </galleria.glassfish.testDomain.httpsPort >

È possibile copiare questo dal profilo dello sviluppo della Galleria-ejb progetto come descritto nella parte 2 . È inoltre dovrebbe già avere il dominio in atto. Avanti fino al maven-surefire-plugin si può vedere, che segue le stesse convenzioni che la galleria-ejb progetto ha. Ma guardando i test-classi si può vedere, che non c'è una singola unità di test qui. Così si può passare direttamente al maven-failsafe-plugin che gestisce i test di integrazione. Vi è un AllPagesIntegrationTest unico che riguardi la prova completa.Andiamo là. 
Si tratta di un TestCase Arquillian che viene eseguito come un client con un'istanza remota. Oltre alla definizione della distribuzione (Deployment @) è inoltre ancora una volta vedere un paio di metodi di impostazione e di tearDown che fanno un po 'di inizializzazione e distruzione. Una cosa deve essere gestito separatamente. Si vede anche un metodo writeCoverageData () in cui ci si collega, ovviamente, a qualche tipo di Socket e legge i dati da esso. Questo è il JaCoCo (Java Code Library Coverage) gancio che può produrre un set di dati di copertura dei test. Per fare questo lavoro dovrete scaricare il pacchetto ed estrarre in un luogo di vostra scelta. Avanti vai al tuo GlassFish test-domain \ config \ domain.xml e aprirlo. Trova il server-config - java-config e aggiungere il seguente lì:

1.<jvm-options>-javaagent:D:\path\to\jacoco-0.5.6.201201232323\lib\jacocoagent.jar=output=tcpserver</jvm-options>

In questo modo l'agente di copertura per GlassFish. Tutta la configurazione fatto ora. Torna a NetBeans, selezionare il profilo di integrazione-test (in NetBeans è possibile farlo selezionando la voce dal menu a discesa accanto alla piccola il martello nella zona icona o utilizzando-Pintegration-test come una riga di comando Maven. La console uscita ti dice, che il dominio GlassFish è avviato e la info.galleria.view.AllPagesIntegrationTest è in esecuzione. Attenzione, un'istanza di FireFox è popping durante questo percorso e l'estensione Arquillian Drone sta guidando i test Selenium. 

Vedere un browser remoto controllato in questo modo guarda e si sente strano, se non avete visto prima. Se tutto funziona si dovrebbe ora vedere questo l'output della console:

1.Test eseguito: 30, Errori: 0, Errori: 0, ignorati: 0, Tempo trascorso: 138,014 sec

Se si utilizza un altro locale di en per il browser potresti aver completamente fallito test. Quindi c'è bisogno di configurare ulteriori Drone per sostenerlo . Drone consente di specificare un profilo di Firefox tramite arquillian.xml. . È possibile creare un profilo di Firefox che è configurato per inviare Accept-Language intestazioni con en / en-US come valore 
Per creare un nuovo profilo, avviare Profile Manager di Firefox con il seguente comando (potrebbe essere necessario chiudere tutte le istanze in esecuzione): firefox-profilemanager (su Windows è necessario eseguire il comando "d: \ ​​complete \ path \ to \ firefox.exe"-profilemanager) in una shell cmd.Ricorda la posizione sul disco in cui viene creato questo profilo - vi servirà in seguito. Per configurare il profilo creato, in Firefox, andare su Opzioni (menu) -> Contenuto (tab) -> Lingue (fieldset) -> Scegli di aggiungere la lingua inglese (e spostarla in alto, come quella che preferiamo). Ora navigare galleria-jsf \ src \ test \ Resources \ arquillian.xml, è possibile aggiungere una proprietà:

1.< estensione qualifier = "webdriver" >

2.< proprietà name = "implementationClass" > org.openqa.selenium.firefox.FirefoxDriver </ proprietà >

3.< proprietà name = "firefoxProfile" > percorso del profilo di Firefox per l'inglese </ proprietà >

4.</ estensione >

Tutto fatto ora. Dovreste essere in grado di eseguire la pulizia completa e processo di costruzione ora senza alcuna prova di fallimento. Un grande "barra verde" :)

Corso Java - Corsi Java - Corsi programmazione Java

 Corso programmazione Android - Certificazione Android