Cos'è il test dei moduli? Definizione, esempi

⚡ Riepilogo intelligente

Il test modulare verifica singoli sottoprogrammi, subroutine, classi e procedure anziché il programma assemblato, in modo che i difetti emergano all'interno di un piccolo blocco di codice ben compreso, dove rimangono economici da individuare e correggere.

🎯 Obiettivo: L'obiettivo è quello di individuare gli errori in un modulo, non di dimostrare che il modulo funzioni.
⚪ Orientamento: La tecnica è in gran parte a scatola bianca, integrata da casi a scatola nera derivati dalle specifiche.
⏩ Parallelismo: È possibile testare più moduli contemporaneamente, il che riduce la durata complessiva del test.
🔗 Due metodi: I moduli vengono combinati in modo incrementale, passo dopo passo, oppure in modo non incrementale in un'unica passata.
🧰 Impalcatura: I driver forniscono dati di test a un modulo, mentre gli stub sostituiscono i moduli che esso richiama.
🆚 Proprietà: I tester scrivono i test di modulo dopo aver scritto il codice, mentre gli sviluppatori scrivono i test unitari durante la fase di programmazione.
⚠️ sfide: Il lavoro non incrementale, i test double fraintesi e le frequenti operazioni di debug assorbono la maggior parte dello sforzo.

Scopri di più

Cos'è il test dei moduli?

Test del modulo Il test modulare è un tipo di test del software che verifica singoli sottoprogrammi, subroutine, classi o procedure all'interno di un programma. Invece di testare l'intero programma software in una sola volta, il test modulare raccomanda di testare i singoli componenti del programma.

Il test dei moduli è in gran parte orientato al modello white box. L'obiettivo del test dei moduli non è dimostrare il corretto funzionamento del modulo, bensì la presenza di un errore al suo interno. Questa distinzione è fondamentale: un'esecuzione che non rileva alcun problema ha confermato ben poco, mentre un'esecuzione che individua un difetto ha raggiunto il suo scopo.

Il test a livello di modulo consente inoltre di introdurre il parallelismo nel processo di test, poiché offre l'opportunità di testare più moduli simultaneamente anziché attendere una build completa.

Perché eseguire il test dei moduli

Si raccomanda di testare i moduli perché modificano gli aspetti economici del rilevamento dei difetti.

Aumenta la probabilità di individuare errori o bug in porzioni più piccole di un programma.
È possibile testare simultaneamente più moduli, pertanto l'approccio supporta i test paralleli.
La complessità dei test può essere gestita facilmente, poiché ogni modulo viene analizzato in modo indipendente.
Un difetto riscontrato all'interno di un modulo è tracRiducibile a una piccola quantità di codice, quindi i tempi di debug si riducono drasticamente.

Come eseguire il test dei moduli?

Progettare a caso di prova è la parte importante del test dei moduli. Durante la progettazione dei casi di test per un test di modulo, un tester deve tenere in considerazione due cose.

Specifiche del modulo
Il codice sorgente del modulo

Analizzare la logica del modulo utilizzando uno o più dei scatola bianca metodi e quindi integrare questi casi di test applicando scatola nera metodi alla specifica del modulo. I valori realistici contano tanto quanto i percorsi scelti, quindi preparate il dati di test Parallelamente ai casi, piuttosto che successivamente.

Una volta progettati i casi di test, il passo successivo è combinare i moduli per il test. Il metodo utilizzato è un incrementale non incrementale metodo.

Metodo non incrementale — Tutti i moduli vengono testati in modo indipendente. Prima vengono combinati tutti i moduli e poi viene testato l'intero programma.
Metodo incrementale — Ogni modulo viene prima testato e poi gradualmente aggiunto alla raccolta di moduli testati. Il processo prevede una ripetizione dei test in modo graduale.
Nell'ambito dei test incrementali esistono due approcci, dall'alto verso il basso and basso verso l'alto test.
Per eseguire il modulo con i dati selezionati, è necessario un driver che fornisca i dati di test, monitori l'esecuzione e acquisisca i risultati.

La scelta tra i due metodi rappresenta un compromesso tra la complessità dell'installazione e la capacità diagnostica.

Aspetto	Metodo incrementale	Metodo non incrementale
pelle mista	Un modulo alla volta, aggiunto a una raccolta testata	Tutti i moduli combinati, quindi testati insieme
È necessario un ponteggio.	Più driver e stub, scritti progressivamente	Meno test double, poiché sono presenti moduli reali
Isolamento dei problemi	Forte: un punto di errore nel modulo appena aggiunto	Debole: un guasto potrebbe avere origine ovunque
più adatto a	Costruzioni di grandi dimensioni con molti moduli interagenti	Programmi di piccole dimensioni con pochi moduli e basso accoppiamento

Driver e stub nei test dei moduli

Il driver menzionato sopra è una delle due metà di una coppia. Poiché un modulo in fase di test raramente si trova all'inizio o alla fine della catena di chiamate, i tester sostituiscono con codice fittizio ciò che manca su entrambi i lati.

Guidatore — sostituisce il modulo chiamante sopra quello in fase di test. Fornisce i dati di test, invoca il modulo, monitora l'esecuzione e acquisisce i risultati. Il testing bottom-up dipende dai driver, perché i moduli inferiori sono pronti prima di quelli superiori.
mozzicone — sostituisce un modulo chiamato al di sotto di quello in fase di test. Accetta la chiamata e restituisce una risposta fissa e nota in modo che il modulo in fase di test possa completare il suo percorso. Il testing top-down dipende dagli stub, perché i moduli di livello superiore sono pronti per primi.

Un caso pratico rende concreto l'abbinamento. Se un modulo di calcolo del pagamento è terminato mentre la schermata di checkout che lo richiama non lo è, un driver fornisce al modulo una serie di totali dell'ordine e registra la risposta. Se anche il servizio di ricerca delle imposte richiamato dal modulo non è terminato, uno stub restituisce un'aliquota fiscale fissa in modo che il calcolo venga comunque eseguito. Nessuno dei due componenti di supporto viene rilasciato; entrambi vengono scartati una volta che arrivano i moduli reali, motivo per cui la mancata comprensione dei test double viene elencata in seguito come una sfida ricorrente.

Suggerimenti di esempio per il test dei moduli

Ecco alcuni suggerimenti da tenere in considerazione prima di eseguire i test dei moduli.

RevEsamina i casi di test prima di utilizzarli.
Evitare confusione sull'origine delle discrepanze.
Utilizzare strumenti di test automatizzati.
Esamina le variabili che dovrebbero rimanere invariate.
Scambiare i moduli tra i tester per evitare autotest.
Riutilizzare i casi di test.

Il quinto consiglio ha un peso maggiore di quanto la sua lunghezza possa suggerire. Uno sviluppatore che testa solo il modulo appena scritto ripete gli stessi presupposti che hanno generato il difetto, quindi la rotazione dei moduli tra le persone è uno dei modi più economici per migliorare la qualità.

Test unitario e test dei moduli

In molti team i due termini vengono usati in modo intercambiabile, tuttavia l'autore e l'ambito di applicazione differiscono.

Test del modulo	Test unitari
I test dei moduli sono una raccolta di test scritti da un tester dopo che del codice è stato scritto da uno sviluppatore	Test unitari sono una raccolta di test scritti da uno sviluppatore durante il processo di sviluppo del software
Il test dei moduli può comportare la combinazione dei test unitari	Il test unitario può testare le unità in isolamento

Test dei moduli vs test dei componenti vs test di integrazione

Il test dei moduli si trova inoltre accanto a due livelli adiacenti che possono essere facilmente confusi con esso. La tabella li distingue in base a ciò che viene testato e a chi lo esegue di norma.

Aspetto	Test del modulo	Test dei componenti	Test d'integrazione
In fase di test	Un sottoprogramma, una classe o una procedura	Un componente autonomo con le sue dipendenze immediate	Le interfacce tra i moduli combinati
Proprietario abituale	Il tester, dopo che il codice è stato scritto	Tester	Tester di integrazione
impalcatura	Driver e stub	Stub per dipendenze esterne	Un numero progressivamente minore di doppi test
Difetto esposto	Errore logico all'interno del modulo	Errore di comportamento nel componente	Errore di interfaccia e di passaggio dati

Nell'uso quotidiano test dei componenti e il test dei moduli sono spesso trattati come la stessa attività, mentre test d'integrazione Inizia solo dopo che i singoli moduli sono stati superati autonomamente.

Sfide nel test dei moduli

Queste sono le sfide che i team incontrano più spesso quando viene introdotto il test modulare.

I test non incrementali richiedono più lavoro — combinare tutto prima significa che un singolo errore può costringere i tester a ricominciare da capo l'intero programma.
Il test dell'incomprensione raddoppia — uno stub che restituisce un valore irrealistico produce un'esecuzione positiva che non dimostra nulla.
I test di debug spesso — il codice di base presenta dei difetti, e il tempo impiegato per correggere un driver è tempo non impiegato per testare il modulo.
È necessario comprendere il codice — l'orientamento a scatola bianca significa che un tester che non sa leggere il modulo non può progettare casi d'uso significativi per esso.

DOMANDE FREQUENTI

La famiglia xUnit supporta la maggior parte dei linguaggi, con librerie di mocking che forniscono gli stub e uno strumento di copertura che mostra quali percorsi sono stati raggiunti. La scelta dipende dal linguaggio del modulo, non dal livello di test.

Un modello legge il codice sorgente del modulo, enumera i rami e propone un caso per ciascuno, includendo i valori limite che un'analisi manuale spesso non considera. RevLa revisione rimane necessaria, perché i casi generati verificano ciò che il codice fa piuttosto che ciò che la specifica richiede.

Sì, e la creazione di scaffold è il contesto in cui tali assistenti danno il meglio di sé, poiché un driver o uno stub è un codice ripetitivo con una struttura nota. I valori restituiti necessitano comunque di una decisione umana, perché uno stub dall'aspetto plausibile può nascondere proprio il difetto che si sta cercando.

Abbastanza da garantire che ogni ramo e ogni confine del modulo siano stati esercitati almeno una volta. Un obiettivo percentuale da solo è fuorviante, perché un'elevata copertura delle affermazioni può comunque lasciare interi risultati decisionali non testati.

Dopo la compilazione di un modulo e prima che le sue interfacce vengano testate congiuntamente, si tratta del primo livello di test applicato al codice consegnato. Per questo motivo, i difetti individuati in questa fase non raggiungono mai le fasi di integrazione o di sistema.

Segui il codice esistente. L'approccio top-down è adatto a progetti in cui la logica di controllo viene scritta per prima e i moduli di livello inferiore vengono simulati; l'approccio bottom-up è adatto a progetti in cui i moduli di utilità vengono implementati per primi e i driver li richiamano.

Il modulo viene compilato correttamente, la sua specifica è disponibile, le sue dipendenze sono presenti o simulate e i dati di test sono pronti. Iniziare senza la specifica trasforma l'esercizio in una descrizione del codice.

I test non possono mai dimostrare che un modulo sia privo di difetti, ma solo che ha superato i casi simulati. Progettare esecuzioni che tentano di mandare in crash il modulo fornisce quindi maggiori informazioni rispetto alla progettazione di esecuzioni che ci si aspetta abbiano esito positivo.