Newsgroup: it.lavoro.informatica
Titolo: consigli integration test (EJB)

Come consigliate di scrivere gli integration test per EJB?
Il contesto e' il seguente:
 
- si tratta di una webapp ma purtroppo abbiamo REST service solo per una piccolissima parte delle funzionalita', quindi non possiamo usare quelli per i test
- vorrei evitare test che includono l'interfaccia html, anche perche' il web framework usato rende il testing difficoltoso,
- come al solito c'e' un database di mezzo e molti altri servizi AWS con cui interagire
- non ho in programma di switchare a Spring, per ora :)
 
L'unica soluzione che conosco e' Arquillian. Ma esiste qualcuno che sia riuscito ad utilizzarlo per testare un'applicazione reale e non i soliti hello world o progettini open source? Io non ci sono mai riuscito (non in maniera soddisfacente almeno).
 
Altre soluzioni non ne conosco. Avrei pensato a lanciare junit dall'AS stesso, ma  non mi sembra una pratica in voga. 
 
Un'altra sarebbe eseguire dei test js con Nashorn (quindi sempre eseguiti sull'AS), ma anche questa non mi pare una strada battuta dalla community.
 

 Come consigliate di scrivere gli integration test per EJB?
 
Sospetto tu intenda degli end-to-end tests? Esattamente, che spettro di funzionalita` hai necessita` di testare? Devi creare dati di test?
Che CI server usi?


non so se posso chiamarli end-to-end perche' non includono la view. Pero' si', lo spettro di funzionalita' e' tipico degli end-to-end, quindi le funzionalita' principali (login, utente che fa upload di un file, etc).
 
L'architettura e' uno strato EJB che contiene sostanzialmente l'accesso ai dati e  business logic (qualcosa si trova anche nella view a dire il vero). Gli EJB vengono richiamati dalle classi del framework web (che non voglio testare per ora).
 
I dati sono precaricati nel database di test, piu' quelli che vado a modificare/creare in ogni esecuzione del test (che poi viene gettato via grazie a docker).
 
CI: sto provando ad utilizzare AWS Codepipeline. Ho messo in piedi un discreto casino con docker e ansible, il tutto orchestrato da AWS Codepipeline.


Conoscendo le API esterne - che presumibilmente non hai sotto il tuo 
controllo - hai bisogno di un mock-up usando qualcosa di esterno tipo 
MockServer o simili oppure cablati a mano nell'applicazione stessa che 
partono solo durante i test (con Spring sarebbero un comune controller 
attivo per il solo profilo "test")
 
Poi andrei di Cucumber - ma non so come sia integrato con EJB.
 
E... Selenium? (Selenium e Cucumber si parlano molto bene)


Non ho capito molto ma ho l'impressione che la cosa sia reciproca :)
 
Selenium serve per testare applicazioni web, ma ho detto che voglio evitare i test che passano per interfaccia web. Inoltre le REST API permettono di testare solo una piccola parte dell'applicazione, quindi non posso sfruttare neppure quelle.
 
Cmq ho fatto un piccolo test: ho aggiunto un servizio REST che mi servira' solo come backdoor per inviare dal client (junit) script js eseguiti da nashorn sul server stesso. Ovviamente questa backdoor e' attiva solo in ambiente di test.
 
Questo mi consente di eseguire codice a piacimento, quindi anche di invocare gli EJB. Il problema e' che vengono fuori test un po' del cazzo, senza assertion espressive e cmq per testare un risultato intermedio devo serializzare l'oggetto al client e controllarlo la'. Non e' il massimo, ma puo' essere un modo.

 I dati sono precaricati nel database di test, piu' quelli che vado a modificare/creare in ogni esecuzione del test (che poi viene gettato via grazie a docker).
 
Prova a guardare RESTeasy (
https://resteasy.github.io/
). Si integra con 
gli EJB.


resteasy lo sto gia' usando con i pochi servizi REST che abbiamo, ma che c'entra con il mio problema? 
O vuoi dire che dovrei aggiungere uno strato REST per testare gli ejb?

 resteasy lo sto gia' usando con i pochi servizi REST che abbiamo, ma che c'entra con il mio problema? 
 
https://resteasy.github.io/
 
 
"EJB, Seam, Guice, Spring, Spring MVC and Spring Boot integration"

 E... Selenium? (Selenium e Cucumber si parlano molto bene)
 
Selenium, in questo contesto, non porta nessun beneficio.

 Selenium, in questo contesto, non porta nessun beneficio.
 
Dopo che l'ha rispiegato meglio vi do ragione :-)
 
 
Però a questo punto non è un vero e proprio e2e perché si lascia fuori 
lo strato web. Diciamo... un e2e backend-only. Che non c'è nulla di male 
perché gli integration test so generalmente fatti così.
 
OK... In questo caso, seguendo una logica modulare, si creano classi di 
test in cui si fa l'inject di quello che serve e si invocano i test 
sulle API degli EJB. Niente mock, se non lo stretto necessario per 
simulare il servizio esterno che serve ai test. E sì, si possono - e si 
dovrebbero - aggiungere le assert nel servizio "esterno": dopo tutto, 
qualunque esso sia, il servizio esterno si aspetta i dati in un certo 
modo, con certe validazioni; stesso dicasi per le response, e in questo 
modo si possono testare edge-cases che son difficili da simulare anche 
usando una sandbox, tipo timeout, crash, malformed response e chi più ne 
ha più ne metta.
 
Cucumber può nuovamente tornare utile perché aiuta a organizzare e 
strutturare logicamente i test che altrimenti verrebbero fuori un po' "a 
casaccio".

 L'architettura e' uno strato EJB che contiene sostanzialmente l'accesso ai dati e  business logic (qualcosa si trova anche nella view a dire il vero). Gli EJB vengono richiamati dalle classi del framework web (che non voglio testare per ora).
 
Non lo vuoi testare ma son quelle classi che ti dicono come son 
organizzati e richiamati gli EJB. Come ho risposto all'altro post puoi 
seguire una via modulare, seguendo la stessa struttura che hai nello 
strato web.
 
Puoi fare il setup delle classi web facendo l'inject degli EJB? O sei 
costretto a farlo a manella dentro le classi di test?
 
 

 test
 
Sii puo` o usare Arquillian o, se si vuole un e2e puro, tirare su l'AS+EJB, tirare su il db, creare i dati di test (via Liquibase, per esempio), lanciare i propri test BDD. Docker sarebbe perfetto per questo.