Nei test di integrazione, si utilizzano gli oggetti di accesso ai dati per l'impostazione e la convalida o un diverso metodo di accesso ai dati?

2

Durante la scrittura di test di integrazione per oggetti di business logic e oggetti di accesso ai dati, cosa ha più senso usare per l'installazione e la validazione? Nel mio caso, sto utilizzando un ORM nell'implementazione della mia interfaccia di accesso ai dati che verrà utilizzata in produzione e terrò conto dell'implementazione di ORM insieme agli oggetti di business logic per i test di integrazione. Dato che l'implementazione ORM è stata testata separatamente utilizzando le istruzioni INSERT e SELECT per l'installazione e la convalida, è meglio per l'installazione e la convalida del test di integrazione utilizzare l'implementazione ORM dell'interfaccia di accesso ai dati, per utilizzare direttamente l'ORM, per utilizzare quelli INSERT e SELECT istruzioni, o per fare qualcos'altro, modifica: e perché?

L'ORM in questo caso è NHibernate, l'implementazione ORM dell'interfaccia di accesso ai dati è un semplice pass-through al provider LINQ di NHibernate che fornisce anche semplici meccanismi di impaginazione e ordinamento. Sono curioso di sapere cosa ne pensi, in generale o con questo specifico scenario.

modifica: non sto cercando di sapere quale DAO dovrei connettere agli oggetti BL. Che chiaramente dovrebbe essere lo stesso DAO che verrà utilizzato nella produzione. La domanda riguarda il meccanismo utilizzato per inserire i dati nel database per impostare il test prima la funzione di business logic è testata. Presumibilmente, lo stesso meccanismo sarebbe usato per interrogare il database dopo la funzione di business logic è stata testata. Ecco alcuni pseudo-codice di altissimo livello per dimostrare cosa intendo:

MyIntegrationTest()
{
    Foo fooBefore = GenerateFooForTesting();
    SomehowInsertIntoDatabase(foo); // What should be used here and why?

    // Plumb things together; actually done using IoC, not hard-coded.
    DaoFactory realDaoFactory = GetRealDaoFactory();
    BizFactory realBizFactory = GetRealBizFactory();
    realBizFactory.DaoFactory = realDaoFactory;

    BusinessLogicObject biz = realBizFactory.BuildBusinessLogicObject();
    biz.DoBusinessWithFooById(fooBefore.Id);

    Foo fooAfter = SomehowGetFooFromDatabase(fooBefore.Id); // Same question.

    Assert.AreEqual(5, fooAfter.SomethingThatShouldBeFiveAfterBusinessIsDone);
}
    
posta Don 01001100 22.02.2012 - 22:02
fonte

3 risposte

2

Ok, proviamo di nuovo: / Se la tua applicazione funzionerà normalmente solo con i dati che sono stati inseriti / recuperati usando il tuo ORM, allora testerei con quello. Se l'applicazione deve funzionare con dati inseriti con altri mezzi (legacy o dati convertiti), allora è necessario pianificare l'inserimento di alcuni SQL grezzi. La ragione per utilizzare l'ORM è garantire che tutte le modifiche apportate vengano testate correttamente "round trip": ovvero, se si aggiunge una colonna a una tabella, è possibile assicurarsi che venga correttamente compilata durante la registrazione e creata e correttamente recuperata quando usato Per i dati legacy, è necessario assicurarsi che il codice funzioni correttamente con i dati che non sono stati sottoposti ai controlli e alla convalida del livello ORM. Assicurati di utilizzare dati errati e dati validi per assicurarti di identificare e gestire correttamente i record non validi.

    
risposta data 27.02.2012 - 21:30
fonte
0

Anche se stai testando direttamente il livello di accesso ai dati, potresti voler aggiungere qualche ridondanza ai tuoi test includendolo anche in un test di integrazione e vedere come collabora con il codice dipendente.

Dipende da cosa stai provando a testare davvero. Per alcuni test potresti voler simulare l'intero livello di accesso ai dati per mantenere i tuoi test veloci e avere un controllo più stretto sulla configurazione del test.

    
risposta data 27.02.2012 - 08:39
fonte
0

Se stai facendo un test di integrazione, stai testando l'interazione tra diversi oggetti in diversi livelli. Pertanto, utilizzerei un setup il più vicino possibile al sistema finale. Spesso puoi svuotare i casi limite in questo modo (ad esempio, l'ORM può generare un'eccezione che non avevi previsto quando la presenti con dati non validi).

    
risposta data 27.02.2012 - 16:53
fonte

Leggi altre domande sui tag