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.
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.
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. |
È 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.
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.
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