Beffardo .nettiers DataRepository chiamate

Question

Ho un progetto che sto usando .nettiers codice generato come il mio DAL.

Al momento, il mio test consistono fisicamente impostazione di test di dati nel database per ogni test, permettendo poi l'nettiers oggetti per colpire il database e restituire come richiesto.

Ovviamente, questo non è particolarmente efficiente e finora il mio 250 dispari prove di prendere circa 10 minuti per l'esecuzione, così ho cercato in aggiunta beffardo nel mio test.

Mentre sono abbastanza sicuro di aver capito i concetti di scherno fuori le chiamate al database, sto avendo problemi di applicazione per nettiers in particolare, dato che è abbastanza fortemente accoppiato al database.

Uno dei metodi voglio testare simile a questa (taglio leggermente verso il basso per brevità):

public class InterfaceManagerService
{
    public DataDocument SaveDataDocument(DataDocument entity)
    {
        var lookupEntity = DataRepository.DataDocumentProvider.GetByDocumentId(entity.DocumentId);
        if (lookupEntity == null)
        {
            File fileEntity = new File();
            fileEntity.Name = entity.Name;

            var savedFileEntity = DataRepository.FileProvider.Save(fileEntity);

            entity.FileId = savedFileEntity.FileId;

            var savedEntity = DataRepository.DataDocumentProvider.Save(entity);

            return (savedEntity);
        }             
    }
}

Attualmente, sto usando una versione di prova di Typemock, dal momento che sembra fare ciò che è necessario, ma sono aperto a tutte le alternative, ideale open source.

Il primo problema che ho incontrato a lavorare fuori se dovrebbe essere la creazione di una deriso istanza di InterfaceManagerService, o di DataRepository o Entità a se stessi (nettiers enti hanno un'interfaccia che potrebbe essere utile).

Il secondo problema è, come creare il falso oggetto deve essere restituito, in quanto nettiers mette un sacco di extra proprietà in soggetti che comporterebbe grandi e ingombranti test se creo un falso istanza di ogni oggetto mi aspettavo.

Credo, in definitiva, sto cercando di direzione nel modo migliore per scrivere unit test per i metodi che uso nettiers repository di dati metodi, ma per evitare di colpire il database, dal momento che non sembra essere molto su di esso su internet attualmente.

Answer 1

Ho intenzione di dare alcuni suggerimenti derivati dalla mia esperienza personale.Mentre questi non può rispondere a tutte le vostre preoccupazioni, spero che almeno essere di qualche aiuto a voi.

• Rhino Prende in giro è abbastanza noto beffardo quadro.Se siete alla ricerca di un'alternativa al Typemock, vorrei suggerire che.

• Per quanto riguarda se per deridere l'InterfaceManagerService o il DataRepository, direi che dipende da quello che stai cercando di test.Vuoi mettere alla prova la InterfaceManagerService?Quindi vorresti creare oggetti fittizi per il DataRepository.FileProvider e DataRepository.DataDocumentProvider.Se non si ha già familiarità con il concetto di "dependency injection", quindi sguardo;sembra che si dovrebbe applicare alcuni iniezione di dipendenza alla vostra InterfaceManagerService classe (supponendo che si desidera unità di test).

  Se si desidera test delle unità di codice che utilizza il InterfaceManagerService, poi basta prendere in giro la InterfaceManagerService.

...come creare il falso oggetto deve essere restituito, in quanto nettiers mette un sacco di extra proprietà nelle entità che sarebbe risultato grandi e ingombranti test se creo un falso istanza di ogni oggetto mi aspettavo.

• La scrittura di una singola unità di test è facile.La scrittura di test unitari per coprire tutti gli scenari che avete bisogno di coprire, e farlo in modo efficiente, che non si traduce in una grande quantità di codice duplicato in tutta la vostra unità di test è difficile, soprattutto quando gli ingressi e le uscite del metodo testato sono complesse.

  Per questo non ho molto di orientamento, di dire che il mio approccio è quello di cercare di consolidare il test di inizializzazione di logica e test di verifica logica al fine di evitare un sacco di duplicazione del codice, ma allo stesso tempo cerco di evitare di fare il test unitari codice stesso così complicato che diventa difficile capire e soggetta a bug.

  In generale, penso che alla fine l'ho dividendo test di logica in 3 categorie:ingressi/inizializzazione, di aspettative e di risultati e di verifica.Ho scoperto che mettendo la logica in queste 3 categorie è stato molto utile per me, per essere in grado di consolidare il codice comune attraverso test di unità.

  Die-hard di sviluppo test-driven sostenitori sarebbe probabilmente dire che lottano per produrre un pulito insieme di unità di codice di prova è un'indicazione di un difetto di progettazione dell'applicazione.Non ho intenzione di essere in disaccordo con questo, ma devo dire che, purtroppo, i progetti che sono stato coinvolto con non hanno prodotto un test unitari codice di base che è semplice e completa.Il semplice test di unità in genere non ha davvero esplorare scenari problematici, e la vasta gamma di unità di test è generalmente richiesto un sacco di test di logica di installazione.

Answer 2

Uso Typemock e mi piace molto. È davvero facile deridere gli interni di una classe. Quello che cerco di fare è sovrascrivere la classe DataRepository e fare in modo che il restituzione di Typemock sia previsto per il mio componente che lo consuma, per assicurarsi che il componente funzioni come previsto.

Ma in realtà dipende da ciò che stai testando. Se si sta testando il servizio, falsi i risultati previsti del repository e restituisci. Se stai testando il repository, falsi gli interni che il repository consuma. Quindi una buona idea è quella di fingere i riferimenti esterni al componente che stai testando, IMHO.

Hth.