2010-05-02 28 views
6

Ho alcune classi di repository che intendono comunicare con diversi tipi di dati, derivanti da un'interfaccia IRepository.Come si esegue il test dell'unità per una classe che intende comunicare con i dati?

Nelle implementazioni, il codice parla con un'origine dati, sia questa una directory di file XML o un database o anche solo una cache. È possibile testare in modo affidabile una qualsiasi di queste implementazioni? Non vedo l'implementazione di un'implementazione fittizia, perché quindi sto solo testando il codice fittizio e non il codice reale.

risposta

8

No, dovresti usare una simulazione quando stavi scrivendo una classe che utilizza e IRepository. Per le implementazioni di IRepository, è necessario testare l'origine dati appropriata. Per i database, è un po 'un problema - per un file system, un po' meno.

Ove possibile, se puoi esprimere la tua implementazione in termini di flussi o lettori, ti semplificheresti la vita: i test per quelle parti dell'implementazione possono andare contro le origini dati in memoria, o flussi da risorse nel test montaggio. Ovviamente avrete probabilmente bisogno di dei test che vanno a un vero database o al file system, ma si spera di meno.

Sia che si chiami test di "unità" di test di questo tipo, si tratta di come si definiscono i test di unità; personalmente non mi interessa troppo dei nomi in questione, ma I do cura di fare test. In particolare, per i database, questi possono essere piuttosto dolorosi (soprattutto se si desidera essere in grado di eseguire test in parallelo), ma possono anche essere incredibilmente preziosi, secondo la mia esperienza.

1

Penso che se si sta testando il codice che persiste o interroga effettivamente i dati, probabilmente si vuole effettivamente colpire un database.

Questi sono test di integrazione anziché test di unità.

È possibile impostare un database di test, in cui si conosce lo stato dei dati ed eseguire i test a tale scopo. Probabilmente vuoi anche dire ai test che sono diversi dai tuoi test unitari e non devono essere eseguiti ad ogni check in (in nUnit puoi decorare la tua classe di test con un attributo che dice di non funzionare)

1

Broadly parlando, non sarà unità testare qualsiasi codice il cui unico scopo è quello di parlare con una fonte di dati. Potresti comunque voler testare automaticamente il repository, ma tale test sarà un test di integrazione per definizione. Probabilmente non vuoi eseguire questi test come parte dei tuoi build "first pass" come ad es. l'impostazione del database e la pulizia dopo di te possono richiedere una quantità di tempo non trascurabile.

Se il repository ha altre responsabilità (ad esempio, l'implementazione del modello Unità di lavoro), è possibile che si desideri testare le unità separatamente.

1

Ad un certo punto nell'implementazione dell'IRepository verrà utilizzata un'API di terze parti che in realtà leggerà/scriverà in/da database/file/xml. Quello che vuoi fare è deridere quelle API per assicurarti che il tuo codice chiami l'API corretta nell'ordine corretto.

Quindi, se stai leggendo dal database puoi prendere in giro SqlConnection e SqlCommand e assicurarti di chiamare i metodi giusti su quelle classi. Se stai scrivendo su un flusso, puoi prendere in giro il flusso e assicurarti di lavarlo e di eliminarlo (ad esempio).

Problemi correlati