Strategie di verifica

La definizione di una strategia di verifica consente di focalizzare le risorse di verifica sulle opportune parti del codice al momento giusto.

Nello sviluppo di applicazioni medio grandi si pone l'interrogativo del punto da cui iniziare e di come proseguire. Per questo viene proposta una guida in forma di metriche che consentono di analizzare la complessità e l'affidabilità dei metodi, delle classi e del componente sottoposto a verifica (CUT) e decidere la strategia.

La verifica dei componenti, diversamente dalla verifica funzionale, si concentra sui singoli componenti software: classi o metodi nonché JavaBeans Enterprise (EJB) e componenti di servizi Web. Lo scopo della verifica dei componenti è isolare ciascun componente per garantirne la corretta funzionalità. Se necessario, è possibile utilizzare gli stub per sostituire altri componenti, condizionando in tal modo i risultati della verifica in base al comportamento del componente sottoposto a verifica. Una volta che è stata creata una suite di verifica affidabile, è possibile rieseguirla regolarmente per garantire che il componente sottoposto a verifica non regredisca.

È possibile concentrare le verifiche componenti sulle aree elencate di seguito:

Verifica a livello di sottosistema

Lo scopo della verifica a livello di sottosistema (chiamata anche verifica di integrazione) è verificare un insieme di classi integrate la cui funzione è cooperare per fornire un determinato servizio. In un ambiente a più livelli, un sottosistema deve essere uno dei livelli. Lo scopo della verifica a livello di sottosistema è controllare le interfacce tra il componente sottoposto a verifica e gli altri sottosistemi. Tali verifiche controllano le interazioni tra i differenti oggetti del sottosistema.

Benché la verifica a livello di sottosistema dovrebbe giocare un ruolo significativo nella realizzazione complessiva della verifica, si consiglia di aggiungere a questa la verifica a livello di metodo e di classe. La concentrazione sulla sola verifica a livello di sottosistema fornisce soltanto una copertura superficiale dal momento che non consente un sufficiente controllo sulle singole classi.

I due tipi più comuni di verifica di integrazione sono spesso chiamate dall'alto verso il basso e dal basso verso l'alto.
  • La verifica dall'alto verso il basso inizia dalla parte superiore della gerarchia del programma e si sposta verso il basso nelle ramificazioni. Questa può essere svolta dal percorso più breve fino al livello più profondo o in modo trasversale alla gerarchia prima di procedere al livello successivo. Il principale vantaggio di tale tipo di verifica è che consente di visualizzare e verificare in maniera precoce l'architettura globale del sottosistema. Il principale svantaggio è rappresentato dalla necessità di utilizzare gli stub finché i componenti di livello inferiore non sono scritti; questa modalità potrebbe non fornire risultati di verifica affidabili per i componenti di livello superiore.
  • La verifica dal basso verso l'alto inizia tipicamente con la verifica dei componenti di livello inferiore, in una prima fase singolarmente e poi per gruppi. Questa garantisce che ciascun componente sia completamente verificato prima di essere utilizzato dal componente che lo ha richiamato. Tale metodo presenta il vantaggio di rilevare gli errori nei componenti critici in una fase iniziale del processo di sviluppo. Il principale svantaggio è la necessità di creare la maggior parte dei componenti prima di poter presentare un programma di lavoro. I linguaggi orientati all'oggetto si prestano bene alla verifica dal basso verso l'alto.
  • Una terza possibilità è seguire strettamente la strategia del progetto. Ciò significa verificare ciascun componente quando viene creato. La definizione della verifica fa parte del progetto del componente. In base a questa strategia è possibile scegliere l'approccio dall'alto verso il basso o quello dal basso dall'alto.

Verifica a livello di classe

La verifica a livello di classe controlla le interazioni tra i metodi di una classe o di un piccolo gruppo di una classe. Lo scopo è verificare che la classe supporti tutti i casi di interesse per gli utenti e sia sufficientemente solida da gestire le sequenze di metodo impreviste. Per le ragioni che seguono la verifica a livello di classe è generalmente considerata il modo più efficace per verificare il software orientato all'oggetto:
  • La verifica a livello di classe è estremamente efficace in termini di copertura di codice. Anche utilizzando un numero limitato di verifiche è possibile raggiungere dal 60% al 70% di copertura del codice.
  • La verifica a livello di classe riflette i servizi che la classe fornisce agli utenti. Le verifiche sono di semplice scrittura ed è possibile utilizzarle come documentazione per la classe.
  • La verifica a livello di classe rappresenta il livello di verifica ottimale per la ricerca di bug in una fase precoce del processo di progettazione.

Verifica a livello di metodo

La verifica a livello di metodo controlla le diverse condizioni definite nel codice di un metodo in isolamento da qualsiasi altro metodo. Lo scopo è generalmente quello di garantire che il metodo elabori correttamente tutti i possibili input. Nella maggior parte dei casi la verifica di una serie di metodi in modo isolato fornisce una copertura di verifica incompleta: infatti, non è possibile verificare in modo isolato metodi come i metodi privati. I metodi privati possono avere un impatto significativo sullo stato di un oggetto e modificare il comportamento di altri richiami di metodo.

Le interazioni tra i metodi di una classe sono comunemente una fonte di problemi che possono essere più facilmente individuati se il metodo viene utilizzato in differenti scenari. È quindi necessario combinare sempre la verifica a livello di metodo con la verifica a livello di classe o di sottosistema o entrambi. In alcuni casi tra cui la verifica di classi stateless, è possibile concentrarsi esclusivamente sulla verifica a livello di metodo ma in altri casi è possibile decidere di evitare la verifica a livello di metodo e concentrarsi solo sulla verifica a livello di classe.

Il segreto per svolgere una verifica efficace a livello di metodo è stabilire quali metodi effettivamente verificare. La tabella riportata di seguito fornisce risposte ad alcune domande frequenti riguardo alla verifica a livello di metodo:

Domanda Risposta
Che cosa succede se il metodo viene ereditato da una superclasse? Se il metodo viene ereditato da una superclasse e è già stato sottoposto a verifica come parte di una superclasse, non è necessario effettuare su di esso una verifica a livello di metodo nel contesto dell'oggetto ereditato. È consigliabile comunque utilizzare questo metodo nel contesto della verifica a livello di classe dell'oggetto ereditato.
Che cosa succede se un metodo ignora quello della classe principale? Se il metodo è stato verificato nel contesto di una classe principale, è necessario verificare nuovamente il metodo che effettua l'override.
Che cosa succede se il metodo viene sovraccaricato o ignorato? Un metodo è definito sovraccarico quando più metodi della stessa classe si identificano con lo stesso nome ma con parametri differenti. Un metodo è ignorato quando viene dichiarato all'interno di una classe e la sua implementazione viene definita o alterata in una sottoclasse. I metodi ignorati consentono a un tipo di oggetto di essere di natura polimorfica. In entrambi i casi, si consiglia di verificare individualmente ciascuna implementazione di questi metodi di classe.

Verifica di interfacce, di classi astratte e di superclassi

È possibile utilizzare verifiche astratte per controllare interfacceJava, classi astratte e superclassi. Sebbene le classi astratte non possano essere verificate in modo isolato, è possibile applicare una verifica astratta a ogni classe che implementa un'interfaccia, realizza una classe astratta o eredita da una superclasse.

Verifica EJB

La verifica di un Bean Java Enterprise (EJB) generalmente consiste nel verificare la logica business dell'EJB e il successo o l'insuccesso dei metodi del ciclo vitale. Questa operazione viene svolta verificando i metodi definiti nella classe bean richiamando i metodi mediante le differenti interfacce. È possibile che le verifiche risiedano nello stesso contenitore dell'EJB o fuori dal server di applicazioni.

Il modo migliore di verificare un EJB è di distribuirlo su un server di applicazioni e eseguirlo nel contesto del suo contenitore. Se l'EJB dispone di un'interfaccia locale, è necessario sottoporlo a verifica all'interno dello stesso server di applicazioni, ad esempio, utilizzando un altro EJB. Se l'EJB dispone di un'interfaccia remota, è possibile sottoporlo a verifica con un client Java che viene eseguito all'esterno del server di applicazioni a spese dell'aumentato traffico di rete. In entrambi i casi sarà necessario effettuare lo stub dei componenti richiamati dall'EJB sottoposto a verifica in modo da isolare il comportamento dell'EJB.

È possibile verificare i bean di sessione e i bean entity in base alle specifiche di Enterprise JavaBeans 1.1 o 2.0 . È possibile verificare entity beans e bean di sessioni stateful e stateless e con persistenza gestita dal contenitore o dal bean (CMP o BMP). Tutti i bean di cui si intende eseguire la verifica devono disporre di un'interfaccia remota o locale. La verifica di bean basato sui messaggi non è attualmente supportata.

Più modelli di verifica semplificano il processo di verifica di EJB.

Verifica di servizi Web

Quando si effettua la verifica di componenti distribuiti come i componenti Web, l'approccio è sostanzialmente simile a quello utilizzato per ogni altro componente. L'obiettivo della verifica è stimolare l'esecuzione di un servizio Web su un server di applicazioni e di verificare che le risposte del server corrispondano ai valori di ritorno previsti.

L'interfaccia dei servizi Web, come spiegato in un documento di descrizione dei servizi Web (WSDL), è un input necessario per attivare automaticamente la verifica componenti per un servizio Web.

Concetti correlati
Sottosistemi Java
Tecniche di verifica basate sullo stato

Attività correlate
Verifica dei metodi Java
Verifica delle classi Java

Termini di utilizzo | Feedback
(C) Copyright IBM Corporation 2000, 2004. Tutti i diritti riservati.