Come testate i vostri oggetti di business?

Question

Desidero implementare test automatici, utilizzando il framework di testing Microsoft in Visual Studio, per i miei progetti di sviluppo software. Ho creato alcuni test e, tutto sommato, è abbastanza facile da usare.

Quali sono alcune migliori pratiche per affari test oggetti, più specificamente quelli che leggono e scrivono in un database.

È meglio impostare un database di test separato, dal database di sviluppo da cui viene testata l'interfaccia utente e testare solo il database? Fondamentalmente basta riempirlo con dati spazzatura.

È meglio adottare qualche tipo di pulizia dopo la propria mentalità, cioè se sto testando il metodo AddUser, devo aggiungere l'utente, controllare i miei test e quindi eliminare l'utente?

Testate ciascuno dei metodi CRUD in un unico metodo di prova?

Infine, le singole regole aziendali, come la verifica delle stringhe, hanno le dimensioni corrette, le date di inizio sono inferiori alle date di fine, l'ID cliente è un cliente corretto e così via.

Mi rendo conto che questa è una domanda piuttosto ampia ... solo in cerca di qualche direzione ... prendendo piccoli passi.

Maggiori informazioni ...

Lotto di buone risposte! Non sono sicuro che sarei in grado di creare un database fittizio. Sto usando CSLA come framework per i miei oggetti. Ci vorrebbe qualche serio refactoring per renderlo testabile con oggetti finti. Ho intenzione di esaminare questo. Sebbene, ad un certo punto, I do voglia testare l'interazione del database ... quando si utilizza un database di simulazione, dove/quando si verificherà effettivamente la comunicazione del database?

Un'altra domanda ... è meglio mantenere ogni metodo di test non dipendente da altri test?

Answer 1

Idealmente, si avrebbero oggetti business che non accedono direttamente al database, ma usano oggetti helper o qualche tipo di framework ORM (Object-relational mapping). Quindi puoi testare i tuoi BO senza un database, magari prendendo in giro alcuni oggetti helper. Questo è probabilmente il modo più pulito, perché si evita la complessità di un DB reale e si verifica solo la logica aziendale.

Se non si può evitare di combinare le regole di business e l'accesso DB in una classe (probabilmente una progettazione problematica, ma a volte difficile da evitare), è necessario testare un DB.

C'è praticamente l'unica opzione ragionevole per disporre di un DB separato per il test automatico. I metodi di test dovrebbero eliminare tutto durante l'installazione al momento dell'impostazione, quindi caricare tutti i dati, eseguire il test e verificare i risultati.

Non pensare nemmeno a provare a inizializzare il DB una volta e quindi eseguire tutti i test sugli stessi dati. Un test cambierà accidentalmente i dati e gli altri test falliranno misteriosamente. L'ho fatto e me ne sono pentito ... Ogni test deve davvero stare da solo.

Per fare tutto questo, consiglio vivamente una sorta di framework di test DB. Questi aiutano a pulire il DB, caricare i dati necessari e confrontare i risultati della query con i risultati previsti. Uso DBUnit (per Java), ma ce ne sono molti altri per altre lingue.

Answer 2

Generalmente creo il BO, lo salvi nel db nella configurazione del dispositivo, quindi eseguo test per vari insert/update/select, quindi nel mio teardown cancelli l'oggetto dal database. Mantiene le cose belle e pulite specialmente quando sono coinvolti molti vincoli, il tuo db di test può diventare molto veloce se non rimuovi tutto ciò che crei nei tuoi test.

Answer 3

Si consiglia di implementare gli oggetti business in modo che non siano a conoscenza del database. Utilizzare i metodi sul livello di accesso ai dati che possono salvare/recuperare correttamente gli oggetti di business a seconda del loro tipo (ad esempio, ha una mappatura interna tra le tabelle e gli oggetti a cui corrispondono). Quando si verifica il proprio oggetto business, non è necessario preoccuparsi del database. Basta creare l'oggetto, magari usare la riflessione per impostare campi privati ​​e condurre il test sull'oggetto.

Durante il test del codice che deve interagire con il livello di accesso ai dati, utilizzare il mocking per creare un livello dati fittizio e impostare aspettative su di esso per restituire gli oggetti desiderati o rispondere correttamente ai salvataggi. Potrebbe essere necessario sviluppare il livello dati in un'interfaccia (o avvolgerlo con una classe mockable se si utilizza un framework rigido che non supporta direttamente il mocking). La maggior parte dei framework di derisione richiede che i metodi siano virtuali per consentire la creazione di un'implementazione fittizia. L'uso delle interfacce costringe i metodi nella classe di implementazione a essere virtuali, quindi è molto più semplice essere derisi.

Answer 4

Utilizzare dependency injection. Implementa i tuoi metodi di database in un'interfaccia. Quindi scrivere una nuova implementazione dell'interfaccia con i dati di controllo per testare gli scenari applicabili.

Answer 5

Per verificare DB Access Layer, non è necessario eseguire tutti i test sullo stesso db. Alcuni test potrebbero fallire perché dipendono dai risultati di altri test. Quindi questo non è quello che vuoi. In realtà dopo ogni test, è necessario restituire lo stato del database allo stato originale prima dell'esecuzione del test.

Nella mia pratica, tengo il set di dati di test in un XML e prima di ogni test, imposta i dati in db utilizzando l'XML. Quindi ogni test viene eseguito su un set di dati.

Answer 6

Suppongo che una volta si affermi che è necessario testare gli oggetti di business con un database a caratteri misti. In alcuni casi potresti voler mantenere i dati come parte del test. Gli svantaggi di questo sono test di funzionamento più lunghi e la necessità di pulizia.

Una soluzione a ciò che potrebbe essere di aiuto è utilizzare un database in memoria per i test. SQLite, ad esempio, ti permette di creare database in-memory al volo e quando li smaltisci sono spariti. Questo rende i test molto più veloci e non è necessario impostare il codice di pulizia, mentre si arriva a testare il codice SQL/db tramite test automatici.

Answer 7

(So che Non tiratevi uso di Java, ma la strategia generale di seguito non dipende da Java a tutti)

Sto lavorando su un progetto Java che utilizza un sacco di EJB3 codice/APP. Ho deciso di creare una sorta di contenitore finto in grado di "distribuire" EJB e utilizzare un database in memoria (HSQL) con gestore di entità in ibernazione.

Questo "contenitore" si avvia in meno di 1 secondo e mi consente di testare la maggior parte dei componenti aziendali, inclusi quelli che accedono al database tramite JPA. Se un servizio è, per esempio, troppo complesso da supportare, allora semplicemente uso EasyMock (o qualsiasi altra libreria di simulazione) per creare un servizio falso e collegarlo al "contenitore".

È stato un successo enorme finora, ma mi ha richiesto un paio di giorni per implementare l'infrastruttura finta.

Answer 8

Ulteriori informazioni su TDD con CSLA sono disponibili nelle risposte a this question. Soprattutto this one.

Anche this question potrebbe essere interessante.