Il paradigma che sta alla base della Service Oriented Architecure (SOA) tenta di affrontare sia le sfide imposte al business dal mercato sia la necessità per l'IT di sviluppare, testare e implementare soluzioni complesse e mai messe in opera sinora. La SOA suddivide infatti le soluzioni complesse in varie componenti (servizi) che presentano una semplice interfaccia verso l'applicazione, incapsulando sia i dati sia i processi. Questi servizi possono essere forniti in-house, da business partner o attraverso servizi commerciali.
Secondo un'ottica di testing, le opportunità più significative offerte dalla SOA risiedono nel fatto che i panorami proposti dalle applicazioni SOA sono "always on", in continua evoluzione, con labili connessioni e di solito coinvolgono più provider (in-house, business partner e servizi commerciali). Infine, la qualità dei singoli servizi non si traduce necessariamente nella qualità generale della soluzione business. E' la qualità dell'insieme che è veramente importante.
Esempio di applicazione all'interno di un panorama SOADiamo un'occhiata a un semplice e piuttosto "grossolano" esempio di applicazione SOA (servizi ampi e complessi), in cui tale applicazione affronta la necessità di vendere media digitali on-line. I livelli di servizio consistono in un'interfaccia di presentazione Web, nella gestione degli account dei clienti, nel catalogo, nel carrello, nel digital fulfillment, nella “storia” dei clienti e nell'accounting che si interfaccia a un database di servizi amministrativi standard. La figura seguente illustra questa soluzione SOA.
Nella prospettiva di testing, focalizzeremo il nostro interesse sul "servizio per il carrello" e sul suo rapporto con l'interfaccia di presentazione e i partner direttamente collegati al servizio, come illustrato nella figura seguente.
Il servizio per il carrello è connesso al catalogo, alla “storia” del cliente e al digital fulfillment in un modo piuttosto libero, mentre presenta uno stretto legame con lo strato di presentazione Web-enabled.
SOA - Unit test e integration testSOA promuove il riutilizzo a livello di servizio piuttosto che a livello di codice/oggetti. Se pensate a ciascun componente come a un vero servizio, ci sono aspetti interni (dati e processo) ed esterni (interfaccia) di tale servizio che devono essere testati.
È opportuno pensare agli aspetti interni del servizio in termini di unit test e pensare alle relazioni con i partner in termini di integration test.
Va sottolineato che nei tradizionali ambienti di sviluppo gli unit test e gli integration test sono spesso ignorati o gli viene assegnata una minima attenzione: l'ipotesi infatti è che il test individui eventuali errori prima che un prodotto raggiunga la fase produzione. Questo non avviene però nel mondo delle SOA, in cui le eventuali applicazioni di un servizio potrebbero essere, e spesso sono, al di fuori del controllo del gruppo di sviluppo.
Unit test: il processo di testing dei singoli servizi
Lo unit test di un servizio deve essere effettuato dallo sviluppatore e dovrebbe essere esaminato da altri persone che si occupano di sviluppo. Come minimo, lo unit test deve essere costituito sia dalla verifica del progetto della unit (servizio) sia dalla validazione dell'implementazione delle unit (servizi).
Lo scopo dello unit test è di scoprire ed eliminare eventuali discrepanze tra le specifiche e l'implementazione. Questo è particolarmente importante in sede di implementazione perché i servizi SOA sono spesso sviluppati in parallelo e sono sottoposti a un continuo sviluppo/deployment. Ciò significa che l'adesione alle specifiche di progetto e la capacità di incapsulare in modo efficace un servizio sono fondamentali al fine di soddisfare gli obblighi contrattuali del servizio. Lo sviluppatore o l'azienda che si occupa dello sviluppo dovrà definire delle matrici per testare le interfacce che il servizio supporta. Questo diventa fondamentale una volta che lo sviluppo si sposta verso l'integration test.
La sfida dello unit test nel mondo SOA non è tanto l'effettuazione del test stesso, quanto la velocità con cui questo viene attuato. Ci sono diversi approcci ben documentati inerenti lo sviluppo e lo unit test che consentono di superare questo ostacolo. Uno di questi approcci che non viene spesso citato è l'applicazione delle tecniche di sviluppo "Agili" in combinazione con in tool di codice che supportano l'integrazione continua. L'impiego di metodologie e tecnologie di questo tipo contribuisce a risolvere le problematiche che nascono dai continui sviluppi/deployment, che sono una caratteristica di distinzione nel panorama delle applicazioni SOA.
Un altro aspetto delle applicazioni SOA, che ha un rilevante impatto sul modo in cui viene approcciato lo unit test, è l'estensione dello sviluppo in-house e dei servizi implementati. Tanto più è "in-house" la soluzione SOA, tanto più il ritmo e la portata delle eventuali modifiche sono sotto il controllo dell'organizzazione che si occupa dello sviluppo.
Integration testing: il processo di test dei servizi integrati
L'integration test di un servizio deve essere valutato sia da parte dei responsabili dell'architettura sia da quelli dello sviluppo. Un test minimo di integrazione deve essere costituito dalla verifica della progettazione architetturale correlata al servizio in prova e dalla validazione dei servizi integrati. Perciò, per ogni servizio questo si traduce nella verifica della funzionalità del servizio stesso e dei suoi rapporti con tutti i servizi circostanti (direttamente collegati).
Nel nostro esempio, l'integration test del servizio per il carrello avrebbe comportato la verifica delle funzionalità e l'integrazione di tale servizio con il servizio di catalogo, con il servizio della storia dei clienti, con il servizio di digital fulfillment e con l'interfaccia di presentazione Web. L'obiettivo è scoprire e affrontare le discrepanze tra le specifiche funzionali e la messa in opera del servizio per ili carrello e la sua responsabilità contrattuale con gli altri servizi (immediati). Ancora una volta, questo è particolarmente importante in sede di implementazione della SOA.
L'indagine oggetto dell'integration testing dovrebbe concentrarsi sul servizio sotto test e sulle sue responsabilità contrattuali con gli altri servizi (immediati). Ci sono diverse ragioni per adottare questo approccio, non ultimo il fatto che l'integration test di soluzioni SOA è estremamente impegnativo: più è ampio il campo di indagine dell'integration test, più il test stesso diventa laborioso.
E' utile concentrarsi sul panorama immediato al fine di garantire che gli obblighi contrattuali siano raggiunti da ciascun servizio e quindi estendere il campo di applicazione del test durante la prova funzionale. La premessa fondamentale è di trattare i servizi come building block che compongono/supportano un particolare evento di business o parte di un evento.
Oggi sono disponibili diversi tool per il test automatizzato delle SOA (commerciali e shareware), che aiutano a eseguire i test dei servizi, e vi sono ancor più tradizionali tool di test che possono essere usati per effettuare la valutazione delle SOA. Molti sono in grado di gestire le descrizioni dei servizi e anche di creare una base di test iniziale a partire da tali descrizioni. Queste prove possono quindi essere automatizzate.
Una volta completato l'integration test dei servizi strettamente connessi, è possibile iniziare i test funzionali. Ed è qui che emergono le vere sfide per il testing di soluzioni SOA. Tali sfide riguardano:
- I servizi di terze parti
- La selezione del servizio (late binding)
- I servizi mancanti/incompleti/modificati
- I servizi distribuiti multi-piattaforma/multi-lingua
