Test più grandi del codice?
Dipende.
A volte il test sarà più complesso.
A volte il codice sarà più complesso.
Rifattorizzazione per semplificare codice e casi di test
Potrebbe valere la pena prendere in considerazione alcune semplificazioni e refactoring se le cose stanno diventando esponenziali per te.
Ho lavorato con diversi progetti di manutenzione che sono stati disseminati di lezioni di Dio. Questi tendevano ad essere molto più gestibili quando refactored in classi più piccole.
Alcune classi non sono minime e una ricerca di codice ripetuto, e il refactoring per eliminare la ripetizione ha il potenziale per ridurre significativamente la superficie del test.
Black Box vs. Glass Box Testing
Un problema che si pone è quello della metodologia TDD. Quando la storia dell'utente cambia, questo produce più test. All'esecuzione iniziale, falliscono e viene scritto più codice per farli passare. Quando passano, la user story è implementata e spediamo. Naturalmente, nella vita reale, le cose potrebbero non essere così pure. Tuttavia, credo che valga la pena chiedere quanto la storia utente elabora i casi di test? I test case sono funzionali, test della scatola nera basato sull'esercizio degli input validi e non validi?
Dalla tua descrizione sembra che alcuni dei casi di test siano finalizzati alla copertura delle dichiarazioni. Mi piace la copertura informativa, ma ci sono anche molti altri tipi di copertura. Ci sono metodi per ottimizzare i casi di test di copertura che dovresti prendere in considerazione se trovi che parte del tuo alto numero di casi di test è dovuta alla forza bruta che costringe le cose a passare attraverso ogni linea.
Tipi di copertura del codice
Il seguente link illustra con una bella grafica diversi tipi di copertura. Non sostengo o non ho un'opinione sul loro prodotto, solo sul loro diagramma.
link
Nel loro esempio mostrano la condizione / copertura delle decisioni modificate e stabiliscono che per il codice che mostrano, quattro test case eseguono entrambe le istruzioni e causano la ramificazione nell'istruzione if per ogni tipo di condizione che potrebbe verificarsi. Scoperta di casi di test quando i criteri decisionali sono confronti annidati come
if (a < 5) // d1
if (b < 10) //d2
a = 7;
if ((a + b) < 8) //d3
c = 5;
può essere più difficile da analizzare per i valori del test case, ma sai che avrai bisogno di un test case con un < 5 e a > = 5 dal primo se, e anche b < 10 e b > = b dal secondo if.
Perché in alcuni percorsi a sarà l'input, e altri a sarà un valore modificato (a = 7), potresti aver bisogno di usare una tecnica chiamata esecuzione simbolica dove la terza se viene analizzata in termini di a 'e a ''. Per eseguire c = 5, è necessario un caso di test in cui la condizione è soddisfatta. Dovrai anche eseguire un test in cui c non viene mai assegnato.
Un elenco di casi di test che penso riguardi tutto:
T1: a=4, b=9 => a'=4, a''=7, covers d1=true, d2=true, d3=false
T2: a=5, b=9, covers d1=false
T3: a=4, b=10, covers d2= true
Ma come viene coperto d3?
Assegnare a in se la seconda istruzione rende l'analisi più complicata a meno che non facciamo questo con esso.
((a' + b) < 8), ((a'' + b) < 8)
((a' + b) < 8), ((7 + b) < 8) // Remember a'' = 7
((a' + b) < 8), (b < 1) // Remember a'' = 7
T4: a = 1, b = 0, copre d3 = true
L'esecuzione simbolica è una tecnica correlata al test che è possibile utilizzare per ridurre i casi di test necessari per eseguire la copertura decisionale. Non è una lettura facile, ma una carta classica sull'argomento è:
link
Ci scusiamo se questo si allontana troppo dalla tua domanda originale. Spero che sarà di qualche utilità.