Cattiva idea di utilizzare gli stessi casi di test per più parti di un algoritmo contiguo?

0

Sto lavorando su un algoritmo che è suddiviso in più parti, ognuna delle quali svolge compiti diversi ma è più o meno separata dalle altre, con cui intendo l'unica interazione tra le parti è il passaggio di un singolo pezzo di dati da una parte all'altra come un nastro trasportatore. Stavo facendo alcuni test unitari per l'algoritmo e mi stavo chiedendo, è una cattiva idea utilizzare gli stessi casi di test per testare ogni parte dell'algoritmo?

All'inizio pensavo che sarebbe stata una buona idea, dal momento che mi ha risparmiato dover riscrivere un intero nuovo set di casi di test per ogni passo dell'algoritmo, ma man mano che mi sono approfondito ho capito che alcune parti dell'algoritmo erano più specifico di certi compiti rispetto ad altri.

Ad esempio, un passo dell'algoritmo legge un file e sputa un insieme di stringhe, che viene poi utilizzato da un passo successivo nell'algoritmo per produrre un altro insieme di oggetti completamente diversi. Dovrebbero essere progettati test separati per testare specificamente l'integrità di questo primo passo?

Un'altra cosa che mi ha spinto all'idea di utilizzare gli stessi casi di test per più passaggi nell'algoritmo è che l'output di un passaggio potrebbe essere completo e privo di senso per il passo che lo procede. Quindi un caso di test potrebbe passare per un passo nell'algoritmo, ma fallire nel passaggio successivo perché, nonostante il fatto che il passaggio precedente sia stato in grado di analizzare correttamente i dati di input, l'output non è utilizzabile per il passaggio successivo.

tl; dr dovrebbero essere usati gli stessi test per tutti i passaggi di un algoritmo?

EDIT (In risposta a possibili duplicati ): Da quello che posso dire, quella domanda non sembra essere una domanda su un algoritmo lineare (come il modello di nastro trasportatore che ho descritto sopra), sembra invece di parlare della combinazione di dati provenienti da più componenti individuali non contigue. Inoltre, non chiede se gli stessi test debbano essere utilizzati per tutti i passaggi.

    
posta user3002473 21.07.2015 - 08:31
fonte

1 risposta

2

Una buona guida è che i tuoi test dovrebbero esercitare tutto il codice che hai scritto.

Se input diversi causano percorsi di codice diversi da eseguire, è una buona idea scegliere gli input di test in modo che ogni percorso sia coperto. Test più approfonditi cercano anche di garantire che ogni percorso sia coperto in circostanze diverse, in particolare con valori estremi, condizioni al contorno, ecc.

Il fatto che il tuo algoritmo sia in più parti non modifica questi principi. Dal momento che dici di avere una scelta che immette i dati da utilizzare per testare diverse fasi di elaborazione, presumo che i passaggi del tuo algoritmo possano già essere chiamati separatamente. Questo è un design eccellente e semplifica i test perché è possibile ottenere la copertura con meno sforzo (se tre passaggi hanno quattro percorsi ciascuno, sono necessari solo 12 casi di test, non 64).

Se i casi di test riflettono gli usi reali a cui verrà applicato il tuo algoritmo, allora è una buona idea usarli per tutti i passaggi - dopotutto, questo è ciò che sta per accadere.

È vero che se parte dell'algoritmo fallisce e impedisce il funzionamento del prossimo stage, ciò impedirà di catturare bug nel secondo stadio. Tuttavia, dovrai prima aggiustare la prima parte prima di pubblicare il codice, e la suite di test dovrebbe riuscire al 100% prima che tu abbia finito, quindi non ha molto senso scegliere i casi di test per aggirare i difetti conosciuti. I difetti non dovrebbero essere lì in primo luogo, quindi devi lavorare sulla prima fase, non importa cosa, ed è più semplice farlo prima. Ti risparmia lo sforzo di rendere i tuoi test robusti contro errori che non possono essere autorizzati a rimanere nel codice in ogni caso.

    
risposta data 21.07.2015 - 08:46
fonte

Leggi altre domande sui tag