Creazione di dati fittizi per il test dell'unità

Question

Mi considero ancora piuttosto nuovo per la scena TDD. Ma trovo che non importa quale metodo io usi (mock framework o stubing miei oggetti) trovo che devo scrivere molto codice per creare dati mock. Mi piace l'idea di caricare gli oggetti per creare un database in memoria. Ma quello che non mi piace è ingombrare i miei test con una tonnellata di codice al solo scopo di creare dati falsi. Questo è specialmente il caso in cui i dati devono tener conto di tutti i diversi casi.

Mi piacerebbe qualche suggerimento per un modo migliore di farlo.

Mi sembra che dovrei essere in grado di caricare i dati una volta in uno stato noto da qualche archivio dati e quindi potrei usare un'istantanea di quello stato che viene caricato nel setup di test/inizializzare prima di ogni metodo di test viene eseguito. Ciò consentirà di soddisfare le corrette pratiche di test fornendo al contempo comodità e mi consentirà di concentrarmi sulla scrittura di test anziché sulla scrittura di codice per creare dati di test "a mano".

Answer 1

Potrebbe essere possibile provare la libreria NBuilder. Fornisce un'interfaccia molto fluida ed è facile da usare. Puoi usarlo per generare istanze singole di una classe con valori defualt o generare liste con valori predefiniti o sovrascritti. Puoi dare un'occhiata a this uno.

Answer 2

So esattamente cosa intendi. Penso che un buon approccio per risolvere questo problema sia quello di avere un progetto MockFramework separato che ospita tutti i tuoi dati simulati, al di fuori del progetto di test. In questo modo è possibile generare dati di simulazione separatamente, memorizzarli in memoria se si desidera, o meno, e quindi fare riferimento al framework di simulazione dal progetto di test. Se usi un framework di terze parti per fare questo, tanto meglio, ma puoi ancora avvolgere quel framework di terze parti nel tuo finto framework in modo da poter ottenere tutto quel "colla" che crea i dati simulati nel modo in cui ne hai bisogno i tuoi test quindi i test possono essere davvero solo ciò di cui hanno bisogno.

Answer 3

È possibile avere classi Builder che ti aiutano a creare le istanze necessarie/in questo caso quelle che useresti correlate al repository. Chiedi al Builder di utilizzare i valori predefiniti appropriati e sui test puoi sovrascrivere quello che ti serve. Questo ti aiuta a evitare di dover scambiare ogni singolo caso di "dati" per tutti i diversi test (che introduce problemi, perché di solito ci sono casi che non sono compatibili per test diversi).

** Aggiornamento 1: ** Date un'occhiata a www.markhneedham.com/blog/2009/01/21/c-builder-pattern-still-useful-for-test-data

Answer 4

Se usate Net Prova NDBUnit

Si popolano tuo negozio e poi si ritorna vostro DB ad uno stato noto in fase di test, per ogni test. La serie di cast dello schermo Autumn of Agile mostra questo in modo abbastanza dettagliato.

Oppure è possibile farlo manualmente ... creare una stored procedure o qualsiasi altra cosa per troncare le tabelle e copiare i dati nel metodo di smontaggio.

Answer 5

Grazie per tutti i suggerimenti, penso che la soluzione richieda un po 'di tutto. Non voglio che questi test finiscano per essere test di regressione, ma senza qualche tipo di archivio dati esistente tutto si riduce ancora alla creazione dei dati "manualmente" costruendo gli oggetti.

Quello che sarebbe davvero bello sarebbe un framework che mi permettesse di usare il mio DAL esistente per scrivere i dati in codice per me o ottenere i dati in memoria e accedervi come un database in memoria.

Answer 6

Untils.org copre in questo modo meglio di quanto potrei mai.

La loro intera guida è in realtà molto buona.

In pratica, se le unità richiedono "molti dati", potrebbero non essere più test unitari. Consiglierei di provare a testare i pezzi più piccoli individualmente.