Test di verifica dell'unità su un oggetto con molte proprietà

Question

Sono abbastanza nuovo per il test delle unità ma ho completamente l'idea di testare singole unità di codice che eseguono un compito specifico, verificabile, tuttavia, sono nella posizione in cui è necessario scrivere test e fornire confidenza nella precisione di un output di un metodo che agisce su un oggetto con oltre 50 proprietà. Le combinazioni dei valori di queste proprietà producono un output basato su regole iniettate da un oggetto di definizione di regole (utilizzando espressioni lambda) che equivale essenzialmente a una percentuale. Queste percentuali di output sono "mission critical" e sono state testate piuttosto pigramente in precedenza, ad esempio la qualità della classe di definizione delle regole (tutte le percentuali attribuibili per ogni regola si sommano al 100%) ma le proprietà effettive dell'oggetto non hanno stato.

L'oggetto "dati" proviene da un database ma posso, ovviamente, deriderlo. Il mio problema è il numero di permutazioni di dati che richiederebbero il mocking e la quantità di test che dovrebbero essere scritti per garantire che i dati x, y, z (tempi di 50 esponenziali dispari) siano quasi impossibili.

Quindi, la domanda è: in che modo queste situazioni sono verificabili in senso reale. I test di scripting basati su uno stato "corretto" noto e risultati "corretti" sono persino possibili/sensati? I test unitari sono applicabili in questo caso e se non sono alternative.

A proposito, questo è un codice legacy qui con una piccola opportunità di refactoring ma solo se posso garantire la precisione ecc. Entro un intervallo di tempo di un paio di giorni per fare sia il refactoring che i test!

Answer 1

penso che hai dato la metà della vostra risposta te stesso:

Le combinazioni dei valori di queste proprietà producono un output basata su regole iniettato da un oggetto di definizione regola (utilizzando lambda espressioni) che equivale essenzialmente a una percentuale.

Nella tua unit test in corso, si sarebbe beffardo sia i dati e dello Stato. Pertanto, è necessario solo accertarsi che i metodi di input e output si comportino correttamente.

Il test della regola è un'attività diversa. Posso solo indovinare, ma di solito, avrai una tabella di Excel, o qualcosa del genere, di possibili valori di input e output per specificare i requisiti per questa regola. Vorrei convertire la stessa tabella in un formato leggibile (csv) e usarla direttamente per guidare il test unitario della regola.

Answer 2

Beh, non so in che lingua si sta lavorando, ma dopo aver guardato nel tuo profilo penso che .Net potrebbe essere coinvolto.

Se ho ragione, suggerirei di utilizzare Test basati sui dati. MSDN fornisce una breve Quick Start, che mi ha aiutato molto a dadi in: How to: Create a Data-Driven Unit Test Da quando ho letto questo articolo ho startetd di inventare una nuova variante da utilizzare in ogni nuovo progetto ...

Lavorare con questi DDT in Visual Studio consente di memorizzare i dati di test in XML, CSV o in una tabella di database. Forse è possibile scrivere del codice per generare i valori necessari da inserire nei test?

Un secondo consiglio sarebbe il progetto Pex and Moles di Microsoft che analizza il sistema in prova e su questa base genera automaticamente i dati di test per trovare casi di test più estremi.

Answer 3

Se è la quantità di combinazioni che ti trattiene nel tentativo di generare test, puoi dare un'occhiata a all-pair test.

Abbiamo utilizzato PICT da Microsoft per minimizzare con successo la quantità di test, pur avendo una ragionevole sicurezza per la maggior parte dei casi.

Sommario

Per esempio, se si desidera creare una suite di test per la partizione e creazione del volume, il dominio può essere descritto con i seguenti parametri: tipo, dimensione, file system, Formato metodo, Dimensione del cluster e Compressione . Ogni parametro ha un numero limitato di valori possibili, ognuno dei quali è determinato dalla sua natura (ad esempio, Compressione può essere solo On o Off) o come partizione di equivalenza (come Dimensione).

Tipo: primaria, logica, Singolo, Span, Stripe, Specchio, Size RAID-5
: 10, 100, 500, 1000, 5000, 10000, 40000
metodo Format: rapida, lenta
sistema File : FAT, FAT32, NTFS
dimensioni cluster: 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536
compressione: on, off

ci sono oltre 4.700 possibili combinazioni di questi valori. Sarebbe essere molto difficili da testare tutti in un ragionevole lasso di tempo. La ricerca dimostra che testare tutte le coppie di valori possibili fornisce una buona copertura e il numero di casi di test rimane gestibile. Per esempio , {Primario, FAT} è una coppia e {10, lento} è un altro; un caso di test singolo può coprire molte coppie.

Per la serie di parametri mostrata sopra, PICT produrrà 60 casi di prova .

punti portar via

• ci sono oltre 4.700 combinazioni possibili
• PICT produrrà 60 testcases

tutte le coppie

Il ragionamento alla base del test di tutte le coppie è il seguente: i bug più semplici in un programma sono generalmente attivati ​​da un parametro di input singolo .

La prossima categoria più semplice di bug consiste in quelli dipendenti da interazioni tra coppie di parametri, che possono essere catturati con i test tutti coppie.

insetti coinvolgono interazioni tra tre o più parametri sono progressivamente meno comuni, mentre allo stesso tempo essere progressivamente più costoso da trovare esaustivo test, che ha come suo limite la test completi di tutte le possibili ingressi.