Testare il codice iterativo usando le simulazioni: ha senso, come?

Question

Voglio testare un algoritmo usando le simulazioni. L'algoritmo - nell'attuale implementazione - si iterali su una classe di contenitore in più passaggi e set () s e ottiene i valori () s da esso. Lo scopo del test è verificare il risultato finale, memorizzato nel contenitore. Il valore finale dipende dai valori letti e scritti tra i passaggi. Ad esempio, il valore di qualsiasi elemento può cambiare più volte fino a quando l'algoritmo non è terminato e, soprattutto, il suo valore a causa dell'iterazione N dipenderà dal suo valore dopo l'iterazione N-1.

Mi piace l'idea di beffe e mi piacerebbe usarli nello scenario sopra descritto poiché mi permetterebbe di verificare un comportamento errato dell'algoritmo una volta che si verifica, non solo quando il calcolo è finito. Tuttavia, non sono sicuro se questa sarebbe effettivamente una buona idea perché dovrei quindi legare le aspettative per il finto reale vicino all'attuale implementazione (ad esempio, "Aspettatevi (elemento n) e restituisce x, quindi impostato ( Elemento N, valore x+1), un altro GET (n) e restituisce x+1, quindi aspettatevi set (n, x+2) ecc. ").

Sebbene permettami di verificare che i valori intermedi siano come previsto, penso che tali aspettative contraddiranno allo scopo del test (verificare che l'algoritmo calcoli il valore finale corretto) e probabilmente il test fallirebbe se l'implementazione cambia, indipendentemente dalla correttezza della correttezza il valore finale.

Ora la mia domanda: mi manca qualcosa? C'è comunque un buon modo per usare i becchi in questo scenario? O non ha semplicemente senso usarli qui? In che modo gli altri affrontano questo problema?

Nota finale: sto parlando di testare il codice C ++ e dell'utilizzo di Googlemock, se questo fa qualche differenza per la tua risposta.

PS: ho controllato Google e articoli qui (soprattutto Bevido comportamento iterativo - Affronta solo il problema di aumentare un valore di ritorno), tuttavia, non ho trovato nulla di vicino al mio problema.

Answer 1

Direi che se il contenitore è lento in qualche modo o ha effetti collaterali che significano che non puoi leggere i suoi valori senza disturbarlo, allora dovresti usare una finta.

Altrimenti, usare una finta è una perdita di tempo. Useresti una versione derisa di std::vector? Non lo farei; Sarebbe sciocco.

Con il test unitario, se non è possibile testare tutto lo stato interno del tuo algoritmo attraverso vari parametri pubblici, allora quegli stati in realtà non contano. Non possono mai venire in uso reale. Quindi, finché ottieni la risposta finale corretta dal tuo algoritmo per ogni serie di parametri di input, direi che le cose funzionano bene.

Answer 2

Crea il test unitario per l'output finale dell'algoritmo. Volete che i test automatizzati verifichino il risultato previsto perché questo è ciò che utilizzeranno altre parti del programma.

Per quanto riguarda il test dei singoli passaggi all'interno del codice dell'algoritmo, questo è più un lavoro per passare a un debugger, non per test automatizzati. Passare attraverso i meccanismi interni dell'algoritmo dovrebbe essere una cosa una tantum, e una volta che hai ragione, non è necessario continuare a testare i singoli passaggi al suo interno.

Answer 3

I test unitari sarebbero più applicabili sulle parti più piccole che compongono l'algoritmo.

Detto questo, gli strumenti di test unitari sono molto utili per lo sviluppo di algoritmi in questo modo. Non sono affatto male da usare, semplicemente non trattenerli se non sono più validi. Di solito non testeresti ogni iterazione in un test di integrazione, testeresti solo i risultati. Se è utile sviluppare l'algoritmo in questo modo, provalo.

Hai ragione sui bechi, non stai davvero testando molto. Possono essere utili se si desidera controllare alcuni degli input. Molte volte permuterò i miei input in modi esaustivi quando ho scatole nere che non posso controllare. Questi tipi di test funzionano troppo a lungo, però. In genere li commenterò completamente o parzialmente quando entreranno nel controllo della fonte.